1、1/360,软件工程,东北大学信息科学与工程学院 郭军College of Information Science & Engineering, NEUE-Mail: Web Site: ,0.1 关于你,角色学生软件企业开发者和管理者IT应用部门的建设者和运营者能力至少熟悉一种编程语言熟悉OO最好做过一个软件项目,2/360,0.2 关于我,郭军工作单位：东北大学信息科学与工程学院研究方向：软件测试、软件建模主讲课程：软件工程软件建模技术、组件技术工作经历：程序员、项目经理、技术总监助教、讲师、副教授,3/360,4/360,0.3 关于他(1/6),学时：48+16课程结构Chapter
2、 1软件工程概述Chapter 2问题定义和可行性研究活动Chapter 3 需求分析活动Chapter 4 设计活动Chapter 5实施活动Chapter 6测试活动Chapter 7部署活动Chapter 8项目管理活动Chapter 9软件过程模型,5/360,0.3 关于他(2/5),教材软件工程过程、方法和工具2009年12月软件工程及应用/东北大学出版社2007年5月软件工程 / 东北大学出版社 / 王家华 / 中面向对象的软件工程 / 机械出版社 / Timothy C.Lethbridge / 加,6/360,0.3 关于他(3/5),7/301,0.3 关于他(4/5),参
3、考推荐DEV475: Mastering Object Oriented Analysis & Design with UMLDEV396: Essentials of Rational Software ArchitectRational Web Sitehttp:/ Developer Domainhttp:/ 关于他(5/5),Learning UML 2.0Object-Oriented Analysis and Design: Understanding System Development with UML 2.0UML 2.0 in a Nutshell UML 2 Toolki
4、tBuilding Web Applications with UML,9/360,Chapter 1 软件工程概述,1.1 为什么学习软件工程1.2 什么是软件工程1.3 软件工程三视角1.4 教材案例-在线宠物商店,10/360,1.1 为什么学习软件工程(1/6),软件: 新的驱动力In the early 1980s, a front page story in Business Week magazine,11/360,1.1 为什么学习软件工程(2/6),软件的概念Program + Data Structure + Documents Wang Jiahua, 软件工程, pp.
5、1软件的性质复杂性难以描述性不可见性变化性,风险性易于副本的大批量生产强合作性,12/360,1.1 为什么学习软件工程(3/6),软件危机爆发时间1967年NATO的研究组首次提出1968年NATO软件工程会议首次提出软件工程概念1968-2006, 近40年“危机”一词软件危机依然存在,Crisis！,13/360,1.1 为什么学习软件工程(4/6),软件危机面对的问题艺术 vs. 标准化软件需求获取需求变更设计缺陷软件错误的发现软件支持和维护开发速度 vs. 市场需求开发周期过长、开发成本过高研发风险软件Trouble软件开发中的复杂的协作(人员,问题,过程)不同角色的软件神话(管理者
6、,用户,开发者,大众),14/360,1.1 为什么学习软件工程(5/6),采用什么方法缓解危机硬件 ?建筑学?拍电影?软件工程！,15/360,1.1 为什么学习软件工程(6/6),挑战,16/360,1.2 什么是软件工程(1/4),Fritz Bauer:“建立和应用完善的工程原理以便经济地得到在真实机器上可靠和有效运行的软件重原理、轻技术、无度量IEEE：(1)应用系统的有规则的定量的方法开发、使用和维护软件；即应用工程于软件。(2)研究(1)中的方法粗糙,17/360,1.2 什么是软件工程(2/4),Definition软件工程是以质量为核心，为了经济地开发满足客户需求的软件而研究
7、、建立和应用的系统化的、有规则的、可度量的和可控制的工程原则、方法，包括需求分析、设计、编码、测试、部署和项目管理等诸多活动，涉及到软件过程、开发方法、开发工具，甚至企业文化等各个方面。 Guo Jun,18/360,1.2 什么是软件工程(3/4),发展历程 (1),19/360,1.2 什么是软件工程(4/4),发展历程 (2),20/360,1.3 软件工程三视角(1/17),软件工程是一种层次化的技术,21/360,1.3 软件工程三视角过程(2/17),过程定义软件过程由开发或维护软件及其相关产品的一系列活动构成，这些活动从不同的方面定义了软件开发中的任务、涉众、交付物和步骤等流程要
8、素,22/360,1.3 软件工程三视角过程(3/17),为什么需要过程视角？(1/2)软件工作的范围软件的开发风险（规模、周期、复杂度）,涉及整个软件生存周期,扩展到,少，可预知、可控,多，不易预知，不易控制,发展到,只考虑编写程序,23/360,1.3 软件工程三视角过程(4/17),为什么要引入软件过程？(2/2)软件开发的角色软件标准,团队中更多的角色,扩展到,软件产品的标准化,软件开发过程的标准化,扩展到,程序员,过程和活动(1/4),24/360,1.3 软件工程三视角过程(5/17),Process,控制/约束,输入,资源,输出,25/360,1.3 软件工程三视角过程(6/17
9、),What,How,Change,26/360,1.3 软件工程三视角过程(7/17),27/360,1.3 软件工程三视角过程(8/17),过程和活动(4/4)Basic Activities(基础活动)问题定义，需求，规约，设计，实现，软件验证，集成，软件演进/维护，退役Umbrella Activities (辅助性活动)软件项目跟踪和控制，正式的技术复审，软件质量保证，软件配置管理，文档编制，复用管理，度量，风险管理，,Something that covers or protects. 保护物覆盖或保护的事物,28/360,1.3 软件工程三视角过程(9/17),公共过程框架,Co
10、mmon Process Framework,Framework Activities,Task Sets,Tasks,Milestones, deliverables,SQA points,Umbrella Activities,1.3 软件工程三视角方法(10/17),为什么需要方法视角？更快的开发更好的开发,29/360,1.3 软件工程三视角方法(11/17),面向过程的编程,30/360,1.3 软件工程三视角方法(12/17),面向对象的编程,31/360,1.3 软件工程三视角方法(13/17),面向组件的编程,32/360,1.3 软件工程三视角方法(14/17),面向服务的编
11、程,33/360,1.3 软件工程三视角工具(15/17),为什么需要工具视角？对于软件企业实施软件工程非常重要软件工程工具可以辅助学习者对软件工程理论的学习,34/360,1.3 软件工程三视角工具(16/17),工具集,35/360,1.3 软件工程三视角(17/17),视角与活动,36/360,37/360,1.4 教材案例-在线宠物商店(1/3),宠物大战SUN Vs. Microsoft主要功能：列举宠物商品类别和提供搜索功能显示宠物列表和宠物具体信息提供用户登录验证、注册新用户和维护用户信息等功能管理购物车实现结帐处理查询订货情况统计销售记录,38/360,1.4 教材案例-在线宠
12、物商店(2/3),问题(1/2):从何开始？采用什么技术？需要多少时间？需要多少人？哪些角色？能否并行、协作地开发？人力应该如何高效率的投入？开发计划？直接编码？ 需求？设计方案和模型？人机交互的界面？功能优先级？,39/360,1.4 教材案例-在线宠物商店(3/3),问题(2/2):开发风险？可扩展性？复用？设计模式？ 编码规范？需求变更？测试？开发过程？软件度量？ 最后期限？,40/360,2.1 概念2.2 流程2.3 方法2.4 工具2.5 工件2.6 课堂作业和项目实践,Chapter 2 问题定义和可行性分析活动,41/360,2.1 概念问题定义(1/2),What问题定义是软
13、件开发过程当中的一个定义要解决的问题并确定系统范围的活动。Why形成一个早期判断，达成一个最初共识 When项目日程表的最前端占整个软件开发时间中的比例很小,42/360,2.1 概念问题定义(2/2),Who系统分析师、出资方领导、出资方技术人员、开发方领导和项目经理 Where客户现场,43/360,2.1 概念可行性分析(1/2),What可行性研究是以相对短的时间和相对低的成本来确定给定的问题在其约束条件内是否有解、有几种解以及哪个是最佳解。 Why必须要先确立满足约束条件的方案是否存在、是否可行、是否最优，然后再在最优方案的基础上进行开发,44/360,2.1 概念可行性分析(2/2
14、),When项目的早期阶段占整个软件开发时间中的比例较小，但比问题定义活动所消耗的时间长Who系统分析师、出资方领导、出资方技术人员、用户代表、开发方领导、项目经理、架构设计师、领域专家、财务人员、市场人员、软件质量保证（SQA，Software Quality Assure）人员等Where客户现场。,45/360,2.2 流程问题定义(1/1),How,46/360,2.2 流程 可行性分析(1/1),How,2.3 方法(1/10),问题定义方法较小的投入要做什么和为什么要做早期判断(大致范围和投资额)达成共识,47/38,2.3 方法(2/10),可行性分析的角度(1/3)可行性技术可
15、行性操作可行性经济可行性调度可行性其他: 社会可行性、市场可行性、竞争可行性、策略可行性等,48/38,2.3 方法(3/10),分析角度(2/3)评估风险制定软件开发计划(粗糙)制定市场营销计划制定术语表或数据字典,49/38,50/360,2.3 方法(4/10),51/360,2.3 方法(5/10),成本/效益分析方法(1/6)运营效益启动成本+运营成本 启动成本指为了建立新系统所支付的一次性开支运营成本指为了维持这个系统的运行所发生的费用 运营效益指正式运行系统后能够产生的收益,52/360,2.3 方法(6/10),成本/效益分析方法(2/6)投资回收分析法 缺点：忽略了资金的时间
16、因素净资金现值法 货币的时间价值,53/360,2.3 方法(7/10),成本/效益分析方法(3/6)净资金现值法 资金现值的使用承认了货币的时间价值例：小型机的折旧期限为 8年，某公司的计算机系统总投资400万元，项目计划用2年时间完成，第1年投资300万元，第2年投资100万元。系统投入运行后每年运行费用为20万元，经和财务人员共同估算每年可得效益376万元。假定以后每年的费用与效益都相同。假定银行利率为9%。,54/360,2.3 方法(8/10),成本/效益分析方法(4/6)例：获得总经济效益为1073.5万元。投资回收期=2+1+92.1/274.9=3.3（年）,55/360,2.
17、3 方法(9/10),成本/效益分析方法(5/6)成本/效益比较净资金现值系数 例：假定方案A和方案B都可行。方案A的开发成本为10000元，在5年期限内每年可得效益4000；方案B开发成本为100000万元，在5年期限内每年可得效益30000元。假定最小可接受的折扣率为12,56/360,2.3 方法(10/10),例：方案A的净资金现值系数4416/10000=0.44方案B的净资金现值系数8150/1000000.08。,2.4 工具(1/1),字处理软件Microsoft WordWPSVisio.,57/38,58/360,2.5 工件(1/3),问题定义报告和词汇表,问题定义报告日
18、期：2007.05.10 系统分析师：郭军项目名称：在线宠物商店系统使用方： 北京XX宠物商店开发方： 沈阳XX软件有限公司目前问题：手工的处理方式效率低下，商品展示的时间和空间有限，连锁经 营业务信息沟通不畅，市场反应迟钝这些问题导致服务质量不 高，业务数据反馈周期太长，影响决策效率项目目标：加快业务处理速度，提高服务质量项目范围：该宠物商店的业务涉及到全国28家连锁店，可能在3年内扩展到 100家连锁店涉及的主要功能包括宠物信息查询、网上订购初步设想：建立一套B/S构架下的软件系统，投资金额：80万元左右开发周期：12个月左右,59/360,2.5 工件 (2/3),可行性研究报告大纲1)
19、软件工程实践者的研究方法2)RUP：前景3)国家标准：可行性研究报告的编写内容4)企业标准,案例,60/360,2.5 工件 (3/3),词汇表不必说明众所周知的术语完整的词汇表“版本号”和“修订历史纪录” “目录” 系统分析师负责词汇表的完整性,案例,2.6 课堂作业和项目实践(1/6),课堂作业(1/3)为什么需要一个“问题定义”的活动？什么时间展开这个活动？谁会参与“问题定义”活动？问题定义报告的内容有哪些？,61/38,2.6 课堂作业和项目实践(2/6),课堂作业(2/3)什么是可行性研究？为什么需要一个“可行性研究”的活动？什么时间展开这个活动？哪些涉众会参与这个活动？列举5个方面
20、的可行性考虑，简单解释其中每一个方面。项目方案是否经济可行的依据是什么？,62/38,2.6 课堂作业和项目实践(3/6),课堂作业(3/3)什么是项目的启动成本和运营成本？什么是项目的运营效益？什么是投资回收分析？缺点是什么？什么是净资金现值法？优点是什么？可行性研究报告的内容包括哪些？分析假定在开发在线宠物商店系统时，提出了两个方案，即方案A和方案B，这两个方案都可行。方案A的开发成本为200000元，在5年期限内每年可得效益60000元；方案B开发成本为800000万元，在5年期限内每年可得效益200000元。假定最小可接受的折扣率为10，哪个方案是可接受的呢？,63/38,2.6 课堂
21、作业和项目实践(4/6),项目实践(1/3)根据你对宠物商店的理解，制定一个在线宠物商店系统的问题定义报告。根据你对在线宠物商店系统的理解，请提交一份可行性分析报告,64/38,2.6 课堂作业和项目实践(5/6),项目实践(2/3)某大学一直没有一个统一的课程网站，这使得学生在选课、查询课表、上交作业、在线学习、下载课件等方面存在诸多不便，同时教师也不便于查询花名册、提交成绩单等。开发一个统一的课程网站的目的是。根据你对该项目的初步了解，制定一个课程网站的问题定义报告。,65/38,2.6 课堂作业和项目实践(6/6),项目实践(3/3)根据你对大学课程网站的了解，制定一个课程网站的可行性分
22、析报告提交一个在线宠物商店的词汇表，其中至少包括5个词汇,67/360,3.1 概念3.2 流程3.3 方法3.4 工具3.5 工件3.6 课堂作业和项目实践,Chapter 3 需求分析活动,68/360,3.1 概念(1/7),What(1/3)需求：主要是在产品构建之前确定的系统必须符合的条件或具备的功能，它们是关于系统将要完成什么工作的一段描述语句，它们必须经过所有相关人员的认可，其目的是彻底地解决客户的问题。 需求文档一组需求的集合 用户需求文档、系统需求文档和软件规约文档,69/360,3.1 概念(2/7),What(2/3),70/360,3.1 概念(3/7),功能性需求和非
23、功能性需求 功能性需求：描述了系统应该做什么，即具备的功能或服务。（输入、输出和计算等）非功能性需求：描述了系统必须遵守的约束条件。（响应时间、吞吐量 、可靠性、可移植性、可扩展性、易用性、安全性、资源要求、可复用性、技术要求、文化和政策需求、法律需求、道德要求、隐私要求，等等） 描述需求的标准是完整的、正确的、必要的、无歧义的、可行的、可验证的以及被设置了优先级别的。,What(3/3),71/360,3.1 概念(4/7),Why需求不一致、模糊、矛盾需求变更客户忽略领域常识/知识/术语 客户集中于现有系统的不足之处，而忽略了系统要实现的关键功能零碎、无组织、不明确、表达不清不分轻重缓急,
24、72/360,3.1 概念(5/7),When项目的早期阶段？,贯穿于整个软件开发过程的需求活动,73/360,3.1 概念(6/7),Who系统分析师、需求阐释者、客户代表、用户代表、开发方领导、项目经理、架构设计师、领域专家、财务人员、市场人员、软件质量保证（SQA，Software Quality Assure）人员、程序员、测试人员、部署人员、技术文档编写人员、培训人员等。Where调研时，在客户现场编纂软件需求规约文档时，可以在开发单位复审相关的需求文档时，根据需要来安排,74/360,3.2 流程,3.3 方法,3.3.1 需求分析的通用原则 3.3.2 网罗需求的方法3.3.3
25、传统的需求分析方法3.3.4 基于UML的需求分析方法,75/38,76/360,3.3.1 需求分析的通用原则(1/12),1)循序渐进理由系统的规模越大且复杂-难以一下子理解完整急于求成- “边建边改” or 错误 or 功能不完善步骤采集原始需求整理需求建立需求分析模型编写需求规约文档复审,77/360,3.3.1 需求分析的通用原则(2/12),1)循序渐进,78/360,3.3.1 需求分析的通用原则(3/12),2)自顶向下，逐层分解理由庞大的、复杂的系统很难一下子被完全理解 小鸟视角分解分解还是分割？ 怎样分解？分解多少/多深为宜？,79/360,3.3.1 需求分析的通用原则(
26、4/12),2)自顶向下，逐层分解,80/360,3.3.1 需求分析的通用原则(5/12),3)与实现分离 理由避免记录一些因为当前的技术才存在的需求，或者使用一些可能不适合新产品的技术避免对实现的方式做出束缚。除非已经严格的做出要求，否则一般不应使用属于实现的描述各尽其责解决办法职业化、专业化的需求分析人员复审,81/360,3.3.1 需求分析的通用原则(6/12),4)定义需求属性理由每个需求仅仅是几行描述语句吗？评估测试故障对需求的影响评估用户对系统的满意程度 估算开发成本 管理项目的规模 分配开发资源 安排调度计划 管理需求变更 管理项目风险,82/360,3.3.1 需求分析的通
27、用原则(7/12),4)定义需求属性属性包括每个需求并不仅仅是一行描述语句。每个需求都有类型、原因、开发优先级、风险、客户满意度、客户不满意度、依赖关系、冲突关系，以及来源等属性随着开发的深入，还可以继续丰富需求的属性，如开发难度、开发工作量等,83/360,3.3.1 需求分析的通用原则(8/12),5)可验证性 理由证明所开发的系统符客户和用户的要求的依据 不可验证的需求，仅仅是对需求的一种主观愿望，对于设计和测试等活动而言都是缺乏意义的度量出系统实现的质量,84/360,3.3.1 需求分析的通用原则(9/12),5)可验证性 非功能性需求的可验证性易用性性能可靠性安全性,85/360,
28、3.3.1 需求分析的通用原则(10/12),6)可追踪性 需求的追踪路径,86/360,3.3.1 需求分析的通用原则(11/12),6)可追踪性理由跟踪问题：在工件的转换过程中，可能会出现很多问题，而问题存在传递性开发成员误解需求 错误地使用需求 变更需求 分析潜在变更的影响核实通过实施系统所有的需求都已经被实现,87/360,3.3.1 需求分析的通用原则(12/12),7)其它原则使用术语尊重客户的意见重视复用需求对变更进行管理要求“确认需求”,88/360,3.3.2 网罗需求的方法(1/1),与用户交流的方式用户访谈做学徒讨论会头脑风暴交流手段 使用思维图，使用鱼骨图，使用需求卡片
29、,89/360,3.3.3 传统的需求分析方法(1/1),3.3.3.1 数据流程图3.3.3.2 状态变迁图3.3.3.3 Petri网3.3.3.4 数据字典3.3.3.5 判定表和判定树,90/360,3.3.3.1 数据流程图(1/20),什么是数据流程图是一个分层的概念模型，分为三个层次：总体图、零级图、细节图，分别描述系统的不同特征Data Flow Diagram, DFD优点容易理解，容易在开发方和用户方之间进行交流，以及在开发组织内部交流,91/360,3.3.3.1 数据流程图(2/20),表示符号外部实体数据处理 数据存储数据流,92/360,3.3.3.1 数据流程图(
30、3/20),数据变换,93/360,3.3.3.1 数据流程图(4/20),分层表示的数据处理,94/360,3.3.3.1 数据流程图(5/20),分层表示的数据处理总体图：描述了系统和周围环境的关系 零级图：表示一个系统的主要功能或者是一个大型系统的主要组成子系统细节图：表示一个复杂的处理的详细内部表示,95/360,3.3.3.1 数据流程图(6/20),分层表示的数据处理总体图,96/360,3.3.3.1 数据流程图(7/20),分层表示的数据处理零级图,97/360,3.3.3.1 数据流程图(8/20),分层表示的数据处理细节图,98/360,3.3.3.1 数据流程图(9/20
31、),数据流程图绘制的有关规定(1/2)外部实体只能出现在总体图和零级图中 数据存储只能出现在零级图和细节图中 数据存储在分层的DFD图中只能出现一次数据存储必须既有读操作，也有写操作 数据流要有名字 数据流必须开始或结束在处理圆圈上数据流不表示有关的控制逻辑,99/360,3.3.3.1 数据流程图(10/20),数据流程图绘制的有关规定(2/2)每个处理要有编号，但不表示先后顺序每个图中处理的数不应超过9个 每个处理应该既有输入的数据流，也有输出的数据流 子图与父图中对应的处理必须执行相同的功能，并且子图与对应的处理流入和流出的数据流相同 输入/输出命令不能作为DFD图中的处理,100/36
32、0,3.3.3.1 数据流程图(11/20),规定举例1,101/360,3.3.3.1 数据流程图(12/20),规定举例2,102/360,数据流程图(DFD)规定举例3,规定举例3,103/360,3.3.3.1 数据流程图(14/20),规定举例4,E1-DS1数据流未与处理相连DS1-DS2数据流无处理处理P1无输出数据流 处理P2无输入数据流数据存储DS2无读操作 所有数据流没有名字,2,104/360,3.3.3.1 数据流程图(15/20),规定举例5,DS1无写操作,105/360,阿,DS2无写操作,DS2读操作的数据流无名称,相对于零级图中的过程P1，少数据流A4,DS1
33、与零级图中的数据存储重复,106/360,A,B2应指向一个处理，而不应直接指向数据存储，我们规定数据流至少有一端必须和处理相联。,相对于其父图中过程P1.2,此处多了数据流A4,过程P1.2.3无输入,107/360,3.3.3.1 数据流程图(18/20),例子,108/360,Data Flow Diagrams,Example,109/360,3.3.3.1 数据流程图(20/20),例子,110/360,3.3.3.2 状态变迁图(1/3),表示符号状态：是可以被观察到的系统的行为模式 圆圈或矩形表示，并在圆圈或矩形中标明状态的名字 变迁表示一种状态向另一种状态的迁移带箭头的线来表示
34、，在线上要标注出事件的名称，需要时也可以和把DFD图中相关的处理标注进来,111/360,3.3.3.2 状态变迁图(2/3),例子1：进程,112/360,3.3.3.3 状态变迁图(3/3),例子2：复印机,113/360,3.3.3.3 Petri网(1/2),表示符号位置（Place）节点表示系统的状态 用圆形符号表示 跃迁（Transition）节点表示系统中的事件用短粗线或矩形表示,114/360,3.3.3.3 Petri网(2/2),例子,115/360,3.3.3.4 数据字典(1/6),数据流程图的问题数据流程图描述了一个系统的主要处理逻辑，所存取的数据文件或数据库及其输入
35、和输出的关系。但不能反映系统的具体细节。什么是数据字典配合数据流程图，反映具体细节。二者结合，精确描述。作用：统一定义，便于通讯，便于共享,116/360,3.3.3.4 数据字典(2/6),元素数据元素最小数据单元 数据流基本数据单元，有关的数据元素所组成的动态的数据结构 数据存储数据结构的载体，静态的数据结构 处理具体处理逻辑,117/360,3.3.3.4 数据字典(3/6),数据元素,118/360,3.3.3.4 数据字典(4/6),数据流,119/360,3.3.3.4 数据字典(5/6),数据存储,120/360,3.3.3.4 数据字典(6/6),处理,121/360,3.3.
36、3.5 判定表和判定树(1/8),判定表左上部：条件或数据元素名称右上部：所有条件组合左下部：处理活动名称右下部：注明条件组合和相应活动对应关系,122/360,3.3.3.5 判定表和判定树(2/8),例子,123/360,3.3.3.5 判定表和判定树(3/8),例子,124/360,3.3.3.5 判定表和判定树(4/8),例子,125/360,3.3.3.5 判定表和判定树(5/8),判定表优点表达逻辑清楚，比自然语言容易理解问题中的条件或数据元素在表中只出现一次判定表缺点用户难以理解随着问题中的条件增多，判定表会变的相当复杂，有时侯一个有经验的分析员也难以画出某些判定表,126/36
37、0,3.3.3.5 判定表和判定树(6/8),判定树是一个树状图根节点表示问题的名字内部节点表示条件，叶子节点表示活动。,127/360,3.3.3.5 判定表和判定树(7/8),例子,128/360,3.3.3.5 判定表和判定树(8/8),判定树优点：理解容易，不需要用户培训绘制方法直观判定树缺点：繁琐，同一条件要书写多次（如前面股票佣金政策用判定树表示，则会非常复杂）,129/360,3.3.4 基于UML的需求分析方法,3.3.4.1 UML简介3.3.4.2 用例图3.3.4.3 活动图,130/336,3.3.4.1 UML简介 (1/20),UML (Unified Modeli
38、ng Language)对软件密集型系统中的制品进行可视化、详述、构造和文档化的语言制品：模型、源代码、测试用例等为什么要使用模型更好的理解问题加强人员沟通更早地发现错误或疏漏的地方获取设计结果为最后的代码生成提供依据,一图在手，,江山我有！,131/336,3.3.4.1 UML简介 (2/20),为什么要学习UML音乐的建模方法：五线谱建筑的建模方法：图纸软件的建模方法：UML软件开发之喻：建造房子(旅行、指挥作战)学习UML：如何从建筑工人成长为建筑师,132/336,3.3.4.1 UML简介 (3/20),UML小史(1/2)方法学大战阶段(上世纪90年代初)统一阶段(1996年)标
39、准化阶段(上世纪90年代末)工业化阶段(2001年至今),133/336,3.3.4.1 UML简介 (4/20),三剑客的贡献(50-1),Grady Booch,Jim Rumbaugh,Ivar Jacobson,134/336,3.3.4.1 UML简介 (5/20),特点统一的标准面向对象可视化、表示能力强大独立于软件开发过程概念明确，建模简洁，图形清晰，容易掌握UML与程序设计语言的区别UML与软件开发过程的关系,135/336,3.3.4.1 UML简介 (6/20),UML的构成：3类主要元素基本构造块事务 (结构事务、行为事务、分组事务、注释事务)、关系(依赖、关联、泛化、)
40、、图(9种)规则命名、范围、可见性、完整性和执行公共机制规范说明、修饰、通用划分和扩展机制(版型、标记型和约束),晕,136/336,3.3.4.1 UML简介 (7/20),UML的构成：视图（Views）图（Diagrams）模型元素（Model elements）通用机制（General mechanisms.）模型驱动架构（Model Driven Architecture ，MDA）特征,137/336,3.3.4.1 UML简介 (8/20),UML的构成：在一个理想情况下, 整个系统可以用一种单一的图来描述，该图明确的定义了这个系统，并且它易于人们之间的相互交流和理解通常这是不可
41、能实现的; 只有非常小的系统才能实现这个目标单一的图不可能捕获到描述系统所需要的所有信息,138/336,3.3.4.1 UML简介 (9/20),UML的构成：多个不同的方面描述功能方面 (系统的静态结构和动态交互）非功能方面 (时间需求、可靠性、部署情况等）组织结构方面 (任务组织结构, 代码模块的映射等)因此，系统需要多个视图来共同描述，其中每个视图代表完整系统描述的一个投影，显示系统的某个特定方面,139/336,3.3.4.1 UML简介 (10/20),UML的构成：每个视图由多个图来描述图中包含强调系统某个特定方面的信息一个特定视图中的图应该足够简单、便于交流，但一定要和其它图和
42、视图连贯一致，这样，所有的视图结合在一起就描述了系统的完整画面,140/336,3.3.4.1 UML简介 (11/20),UML的构成：经常使用的UML视图,Logical View,Process View,ImplementationView,DeploymentView,Use-Case View,141/336,3.3.4.1 UML简介 (12/20),UML的构成：图图包括了用来显示各种图形元素符号的实际图形，这些元素经过特定的排列组合来阐明系统的某个特定部分或方面一个系统模型可以有多个不同类型的图图是特定视图的一部分某些图可以是多个不同视图的组成部分,142/336,3.3.4
43、.1 UML简介 (13/20),UML的构成：模型元素是用语义，即该元素的正式定义或者在一条明确的语句中该元素所代表的精确意义来定义的一个模型元素可以有一个与之相对应的图形符号, 后者是模型元素的图形表示，即在UML图中表示该元素的图形符号,143/336,3.3.4.1 UML简介 (14/20),UML的构成：模型元素(常见的模型元素),144/336,3.3.4.1 UML简介 (15/20),UML的构成：模型元素(关系也是模型元素),145/336,3.3.4.1 UML简介 (16/20),UML的构成：通用机制(为什么?)UML在所有的图中都使用一种通用的机制来描述图的附加信息
44、一般来说，利用模型元素的基本功能不足以表达出这些信息,146/336,3.3.4.1 UML简介 (17/20),UML的构成：通用机制(1修饰)可以用图形修饰附加到UML图中的模型元素上这种修饰为图中的模型元素添加了视觉效果类和它的实例一个节点和它的实例关系的多重性,147/336,3.3.4.1 UML简介 (18/20),UML的构成：通用机制(注释)为了能够为模型添加那些不能用建模语言来表示的信息，或者为了解释设计说明一个注释可以被放在图中的任意位置，并且它可以包含任意类型的信息. 它的信息类型是不被UML解释的一个字符串，它在UML图中没有特别的含义,148/336,3.3.4.1
45、UML简介 (19/20),UML的构成：通用机制(3 规格说明)模型元素有很多属性，这些属性用于维护该元素的数据值。属性是用名称和一个称之为标识值的值定义的属性用于添加关于元素实例的附加规格说明，通常这些特性并不在图中显示工具,149/336,3.3.4.1 UML简介 (20/20),Specifications,3.3.4.2 用例图(1/33),概念(5)识别Actor (5)识别用例(8)描述用例(14)用例的组织(1),150/38,3.3.4.2 用例图概念(1/5),什么是用例图显示了多个外部参与者，以及它们与系统提供的用例之间的连接UML中，一个用例模型可以由若干张用例图组成
46、Actor、用例和关联关系,151/38,152/360,3.3.4.2 用例图概念(2/5),什么是用例图,153/336,3.3.4.2 用例图概念(3/5),开发用例图的步骤(1)找出系统外部的参与者和外部系统，确定系统的边界和范围(2)确定每一个参与者所期望的系统行为(3)把这些系统行为命名为用例(4)使用泛化、包含、扩展等关系处理系统行为的公共或变更部分,154/336,3.3.4.2 用例图概念(4/5),(5)编制每一个用例的脚本(6)绘制用例图(7)区分主事件流和异常事件流，如果需要，可以把表示异常情况的事件流作为单独的用例处理(8)细化用例图，解决用例间的重复与冲突问题,155/336,3.3.4.2 用例图概念(5/5),难点应该包含哪些用例，如何发现它们依赖于分析人员的个人经验和领域知识启发性原则和用户交互把自己当作参与者确定用例和确定参与者不能截然分开,156/336,3.3.4.2 用例图识别Actor(1/5),Jacobson的建议Actor的主要任务是什么Actor需要了解系统的什么信息？需要修改系统的什么信息? (读/写)Actor是否需要把系统外部的变化通知系统？Actor是否希望系统把异常情况的变化通知自己？,157/360,3.3.4.2 用例图识别Actor(2/5),要点(1/4)Actor在系统边界外部,
