软件工程教案复习李梁市公开课获奖课件

1、软件工程复习 重庆理工大学计算机科学与工程学院 李梁 第1页第1页课程要点第1-3章 软件工程概、软件过程及软件开发模型软件、程序、数据、文档含义软件危机及其表现、处理办法软件工程定义与关键思想软件工程基本原理与原则软件工程基本范型软件过程及软件过程模型软件工程生命周期概念以及它各个阶段内容，各阶段主要任务 软件工程主要开发模型：瀑布模式、增量模型、螺旋模型、面向对象过程模型第2页第2页课程要点第5章 软件需求分析软件需求分析概念、主要过程与环节、软件需求类型软件处理方案：目的、性能指标评价、处理方式、可行性分析。启动分析过程：确认利益相关者、辨认视点、协同工作、初次提问主要需求获取技术：会谈

2、、调查表、场景描述、主要需求描述技术：流程图和用例图第3页第3页课程要点第6章 结构化分析建模分析模型概述结构化分析模型概念 SA概念和SA法主要模型（功效、数据、行为）掌握数据流程图基本画法，会画数据流程图掌握数据字典书写格式，会编写数据字典对已明确需求软件，会设计其主要数据流程图，编写主要数据字典掌握决议树、决议表绘制，熟悉结构式语言表示法；掌握IPO图画法第4页第4页课程要点第8-9章 结构化软件设计系统设计（概要设计、过程设计）任务和环节（过程）设计原则：抽象、自顶向下逐步求精、模块化、信息隐藏、重构概念常见模块独立性度量原则：耦合（7种）和内聚（7种）软件模块结构中基本术语和启发式设

3、计谋略：深度、宽度、扇出、扇入、调用、判断调用、数据信息、控制信息掌握概要设计（总体设计）绘制工具：层次图和HIPO图、软件结构图掌握SD法设计过程与环节会区别变换型、事务型数据流图，并掌握相应映射办法会使用SD法将DFD转映射成模块结构图理解对模块结构图启发式设计谋略第5页第5页课程要点第8-9章 结构化软件设计知道详细设计（过程设计）内容、过程及环节界面设计环节与基本准则会使用常见过程设计工具：程序流程图、NS表、鉴定表、过程设计语言理解编码语言分类，选择设计语言要考虑原因知道常见编程语言和工具（C/S和B/S）知道常见数据库产品知道常见软件CASE工具知道开发规范及编码风格主要内容知道结

4、构化程序设计三种基本控制结构 第6页第6页课程要点第7、10-11章 面向对象分析与设计面向对象办法学概念、特点，与面向过程开发办法区别；面向对象分析设计环节、过程清楚对象、类、实例、消息、属性、办法（服务）、继承、消息、主题概念知道OMT对象建模技术对象、动态与功效三大模型知道UML主要模型（用户、结构、行为、实现、环境）及构成主要图形（对象类图、顺序图、状态图）画法和事务（类、属性、服务、主要关联、多重性、角色、包、泛化、汇集、关联类、用例、事件、状态、消息）对已明确需求描述，会设计其面向对象模型（用例图、活动图、对象类图、行为脚本、顺序图、状态图）第7页第7页课程要点面向对象分析设计技术

5、知道对象、类、实例、属性、行为、继承、消息、包概念知道面向对象需求分析过程知道UML概念和UML基本模型对已明确需求系统，会设计其面向对象模型及动态模型（用例图、活动图、类图、顺序图、状态图）第8页第8页课程要点第11-12章 软件实现知道软件测试目的、原则、原则和测试环节知道黑盒法与白盒法测试技术知道单元、集成、确认、系统测试主要内容，在开发过程中位置和使用主要技术（注意驱动、桩模块概念）会设计黑合测试中档价类划分、边值测试测试实例知道一些主要专项测试（如测试、测试、可靠性测试、性能测试、恢复测试）测试用例设计目的及编制办法理解软件维护概念、任务及软件维护分类第9页第9页重点技术需求调查：业

6、务流程图、用例图、活动图SA法：分层DFD图、数据字典编制（描述）、判断表、判断树SD法：软件结构图、HIPO图、DFD映射办法：变换分析与事务分析OO：对象模型（对象类图）、动态模型（行为脚本、状态图、顺序图）、功效模型（DFD）测试：等价类划分、边值分析设计测试用例注意：案例方案文档（图书、ATM、POS、短信、出卷）第10页第10页软件是计算机系统中与硬件互相依存另一部分，它是包括程序，数据及其相关文档完整集合。程序是按事先设计功效和性能要求执行指令序列数据是使程序能正常操纵信息数据结构文档是与程序开发，维护和使用相关图文材料软件=程序+文档软件危机概念： 软件危机是指在计算机软件开发和

7、维护过程中所碰到一系列严重问题。即包括两方面问题：如何开发软件、如何维护软件软件及软件危机01:07:28第11页第11页软件工程基本概念软件工程：是以工程化思想进行软件开发，以生产高质量和高效率软件。教材定义关键观点：把软件看作是一个工程产品。Fritz Bauer定义：软件工程是为了经济地取得能够在实际机器上有效运营可靠软件而建立和使用一系列完善工程化原则。软件工程基本原理：推迟实现观点、逐步求精观点、分解与抽象观点、信息隐蔽观点、质量确保观点软件过程是为了开发出软件产品，或者是为了完毕软件工程项目而需要完毕相关软件工程活动。通常使用生命周期模型简练地描述软件过程软件过程模型：就是把软件生

8、命周期中各项开发活动流程用一个合理框架(开发模型)来规范描述。01:07:28第12页第12页阶段关键问题结束原则（任务）问题定义问题是什么？关于规模和目的汇报书可行性研究是否可行？系统高层逻辑模型；数据流图；成本/效益分析需求分析系统必须做什么？系统逻辑模型；数据流图；数据字典，算法描述 概要设计任何处理问题？系统流程图；成本/效益分析层次图和结构图详细设计如何详细实现HIPO或PDL编码和单元测试正确程序模块源程序清单；单元测试方案和结果测试符合要求软件综合测试方案和结果；完整一致软件配备运营、维护持久地满足用户需要完整准确维护统计01:07:28第13页第13页CMM(Capabilit

9、y Maturity Model)：是用于评价软件机构软件过程能力成熟度模型。是指对过程计划或定义水平、过程实行水平、过程管理和控制水平、过程改进潜力等指标综合评价思想：管理软件过程办法不妥引起问题，造成新软件技术利用并不会自动提升软件生产率和质量。关键：CMM为软件公司过程能力提供一个阶梯式改进框架，它基于过去所有软件工程过程改进结果，吸取以往软件工程经验教训，提供一个基于过程改进框架。CMMI (Capability Maturity Model Integration)：即能力成熟度模型集成，是CMM模型最新版本。能力成熟度模型-CMM01:07:28第14页第14页为公司发展要求过程成

10、熟级别，分为5级：初始级（Initial）：普通公司皆含有可重复级（Repeatable）：成功经验能够重复已定义级（Defined）：一套完整公司过程，人员自觉遵守（培训）已管理级（Managed、已控制）：过程&产品可度量和控制优化级（Optimizing）：过程连续改进作用：从无序到有序、从特殊到普通、从定性管理到定量管理、最后达到动态优化。能力成熟度模型-CMM01:07:28第15页第15页瀑布模型提供了软件开发基本框架。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运营和维护这6个阶段，要求了它们自上而下、互相衔接固定顺序，如同瀑布流水逐层

11、下落而得名它是一个软件开发架构，开发过程是通过一系列阶段顺序展开。每个阶段都会产生循环反馈各个阶段产生文档是维护软件产品时必不可少，没有文档软件几乎是不也许维护。瀑布模型特点：顺序性和依赖性、推迟实现、质量确保观点、是一个线性模型、强调文档作用。瀑布模型01:07:28第16页第16页阶段目的关键问题主要活动阶段结果问题定义发觉事实，并描述问题是什么？事实问题：发觉和研究系统面临问题项目提议书可行性分析明确问题是否值得做？回答是否能够做？问题提议：系统初步调查与分析可行性分析汇报项目立项处理项目的立项问题提议项目：编制初步需求和立项审批表；立项评审项目立项书项目计划处理项目的控制问题项目计划：

12、编制项目计划；评审与修订项目计划项目计划书需求分析回答系统做什么？明确系统不能做什么？问题需求：需求详细调查；问题转化与需求描述；需求评审；需求分析系统分析汇报总体设计处理框架性如何做问题？需求软件架构：需求转化与设计；设计评审与修改；补充调研概要设计汇报详细设计回答详细细节怎么做问题软件架构软件结构：需求分析与研究；设计评审与修改；补充调研详细设计汇报编码回答详细做问题软件结构程序代码：编码、单元测试，硬件安装与测试，系统集成源程序清单测试与公布评价做如何代码软件：系统测试；系统安装与测试；系统公布；系统培训；系统切换系统测试汇报用户手册运营与维护持久地满足用户需要，尽量延长系统生命力软件答

13、案：结构系统之前发觉问题答案，处理问题系统运营日记项目验收汇报系统总结汇报瀑布模型软件开发各阶段任务表第17页第17页面向对象是一个程序设计办法，或者说它是一个程序设计范型。基本思想是使用对象，类，继承，封装，消息等基本概念来进行程序设计。面向对象要素： 抽象：强调实体本质、内在属性，忽略一些无关紧要属性。类实现了对象数据（即状态）和行为抽象，是对象共性抽象。封装性：指所有软件部件内部都有明确范围以及清楚外部边界。 共享性：面向对象特性：对象惟一性；分类性；继承性；多态性（多形性）。面向对象过程模型01:07:28第18页第18页自行开发方式是一个完全依托用户本身开发力量，由用户单位本身员工组

14、成项目组，依据用户单位特点来开发软件系统软件系统开发方式联合开发方式是由用户单位与用户单位外单位共同构成系统开发小组，针对公司详细情况和要求，共同完成系统开发任务外包开发方式是一个“交钥匙”工程开发方式，即承包方依据用户单位提出开发要求，提出软件系统大体框架和开发所需费用等，当双方签署协议后，将系统开发任务所有外包给专业软件开发单位。含有不同功效信息系统作为一个商品越来越多，用户单位可以象购置其它物品一样，到市场购置所需要软件系统，这就是采取购置方式自行开发联合开发外包购买第19页第19页自行开发联合开发外包购买系统分析与设计能力要求非常需要非常需要不太需要不需要编程能力要求非常需要不太需要不

15、太需要不需要系统可维护性容易容易比较困难困难程序可维护性容易相称困难相称困难困难开发费用用于单位外部小大大小用于单位内部大中档小小开发风险大比较大比较大小几种开发方式比较第20页第20页可行性研究可行性研究任务：用最小代价在尽也许短时间内确定问题是否能够处理。可行性研究目标不是处理问题，而是确定问题是否值得处理。经济可行性、技术可行性、操作可行性研究系统是否可行可行性研究输入是系统一个框架描述和高层逻辑模型输出是一份需求开发评价汇报，对需求工程和系统开发是否值得做详细提议和意见。三个问题：系统是否符合机构总体要求？系统是否可在现有技术条件、预算和时间限制内完成？系统能否把已存在其它系统集成？0

16、1:07:28第21页第21页设定优先级设定基本标准：时间投入、成本投入和取得效益(包含无形社会性效益)是最主要三个考评指标。设定优先级原因目标系统能降低成本？何时、何地、怎样降低？花费代价怎么样目标系统能增加收入？何时、何地、怎样增加？花费代价怎么样目标系统能产生更多信息或更多结果吗？目标系统能为客户和企业自己提供更加好服务？目标系统能在合理时间内完成吗？目标系统能为企业提供多长服务期限？具备必要人力、财力、技术、管理和资金资源吗？注意事项系统分析员尽也许采取有形方式评价系统无形成本/效益是影响设定级别主要原因设定优先级是一个综合权衡过程，没有绝正确、只有相正确。仁者见刃，智者见智可行性研究

17、01:07:28第22页第22页软件需求: 就是指用户对自己目的系统在功效、行为、性能和约束等方面盼望。在实际操作过程中，软件需求会跨越多阶段，同时含有重复性。基础性：需求分析是在可行性研究阶段基础上进行，需要仔细研究可行性阶段提出甲乙双方需求并进一步详细化。主要性：软件项目中40%60%问题都是在需求分析阶段埋下“祸端”。由于采用一些不合规范办法，造成开发者开发与用户所想得到软件存在着巨大盼望差别。软件需求分析基本任务是准确地回答“做什么？”。需求分析是系统分析与软件设计之间主要桥梁。软件需求01:07:28第23页第23页功效需求：描述系统预期提供功效或服务。对系统应提供服务如何对输入做出

18、反应系统在特定条件下行为非功效需求：指那些不直接与系统详细功效相关一类需求。通常划分为：产品需求：产品行为需求。机构需求：客户、开发者所在机构政策和要求需求。外部需求：系统外部原因和开发过程总和。领域需求：源于系统应用领域需求。比如，信用卡安全登陆密码隐藏需求等。领域需求经常影响到系统可用性，是基本应用问题。基于功效软件需求分类完整一致准确要 求软件需求类型01:07:28第24页第24页业务需求反应组织机构或客户对系统、产品概括性要求，包括所要达到业务目的，由项目视图与范围文档阐明。用户需求描述用户使用系统而要完毕各种任务，由用例(use case)文档或方案脚本阐明。功效需求定义开发人员必

19、须实现软件功效，源于用户需求，是软件需求阐明书中主要构成部分。 基于层次软件需求分类01:07:28第25页第25页需求分析主要是理解客户需要什么、做什么，分析要求、评价可行性、协商合理方案、无歧义地详细阐明方案、确认规格阐明、管理需求，并将这些需求转化为可行系统。需求分析过程包括初步沟通导出需求分析和精化可行性研究协商与沟通规格阐明需求验证变更管理需求分析过程01:07:28第26页第26页拟定利益相关者利益相关者是指直接或间接从正在开发系统中获益人，或者与正开发系统有利益关系人，因此也称关联人员，按照利益大体分为6类：所有者、用户、系统设计师、系统结构师、系统分析师、软硬件供应商和征询顾问

20、软件开发团队人员构成：作为商品化软件开发团队，其人员构成是以上述前5类人员为主；作为非商品化软件开发团队，以第25种人员为主，此时，用户经常就代表了所有者利益。对于第6类人员，通常不会纳入开发团队。启动分析过程01:07:28第27页第27页软件关联人员关注点因为利益不同，关联人员出发点和关注点也就不同全部者：关注软件范围，如用途、目标、任务、远景、成本和收益等；用户：关注软件需求，如软件是干什么，怎么干，效果会怎么样？系统设计员：关注软件详细设计内容，怎样使用信息技术实现软件？经常，系统设计人员也是系统结构人员；系统结构员：关注软件结构，软件实际技术实现？怎样测试软件？怎样公布软件？系统分析

21、员：关注软件开发工作顺利进行，沟通团体中技术人员与非技术人员，推进团体开发工作；软硬件供应商和咨询顾问：关注信息技术选型、价格、技术要求、交货时间、售后服务和系统架构等。启动分析过程01:07:28第28页第28页识别视点视点：指软件关联人员从不同视角对待该系统。比如，超市POS机收银员关心准确、快速生成一次销售，且没有支付错误；超市售货员关注销售业绩和分成；大学生关注课程作用、学分、成绩和收费等等。问题：软件关联人员视点、信息都可能存在不一致、甚至矛盾地方，软件开发技术人员工作重点就是识别、分析视点中包括信息类型、需求属性等。比如，超市POS机系统就需要制订严格操作流程，如款清帐明、人清日结

22、、高层管理退货退款等启动分析过程01:07:28第29页第29页实例分析：出卷系统利益相关者：教师：关注如何出一份合理试卷，并能依据样式打印与输出。学生：关注如何通过生成一些模拟试题，并在线学习和检查学习结果。题库维护人员：关注试题添加、更新和删除等工作。视点：教师关注自动出卷、手工出卷、试卷编辑和试卷输出。学生关注随时抽卷、联系试卷和评价分析。题库维护人员关注试题管理。非形式化需求分析技术01:07:28第30页第30页非形式化需求分析技术图书馆系统共利益者与视点有：图书流通管理：负责图书借还工作。用户：希望快速得到借书，还书服务，能够续借、预约图书，以及查询个人和图书信息。编目管理员：负责

23、图书管理、用户管理和处理罚金等。01:07:28第31页第31页会谈正式会谈：提出一些可自由回答问题。非正式会谈：提出一些事先准备好议题。情景分析：需求分析从对场景评论中得到信息，然后再将其以形式化方式表示出来。调查表制定调查表分析建立原型界面执行过程非形式化需求分析技术01:07:28第32页第32页场景分析分析员与项目相关人员共同识别出情景，并捕捉这些情景细节。把细节加入到一个纲要需求描述中时，情景尤其有用。情景是对交互实例片断描述，每个情景可能包含一个或多个交互，它们能在不同细节层次上提供不同类型情景信息。情景开始于一个框架，在导出过程中，细节被逐步增加，直到产生交互一个完整描述。非形式

24、化需求分析技术01:07:28第33页第33页一个情景也许包括下列内容： 在情景开始部分有一个系统状态描述； 一个关于原则事件流描述； 一个关于哪儿会犯错，以及如何处理错误描述； 相关其它也许在同一时间进行活动信息； 在情景完毕后系统状态描述。非形式化需求分析技术01:07:28第34页第34页结构化分析（SA，Structured Analysis）办法是20世纪70年代，由E.Yourdon等人提倡一个适合用于大型数据处理系统、面向数据流需求分析办法。结构化分析办法是一个老式系统建模技术，其过程是创建描述信息内容和数据流模型，依据功效和行为对系统进行划分，并描述必须建立系统要素。结构化分析

25、将系统自顶向下逐层分解，达到表示系统目的，它采用一组过程模型图形化地描述一个系统逻辑模型。结构化需求分析指导性原则：理解问题、开发模型、描述需求、建立系统模型、拟定需求优先级、验证需求结构化分析办法是一个建模技术基于计算机系统是数据流和一系列转换构成在模型关键是数据词典，它描述了所有在目的系统中使用和生成数据对象。围绕着这个关键有三种图： ERD、DFD、STD结构化分析概述01:07:28第35页第35页结构化分析模型分析模型目的是为基于计算机系统提供必须信息、功效和行为域阐明。模型是对系统某个方面抽象，抛弃了详细细节，对系统中最突出特性作简化。分析模型所有元素都能够直接映射到设计模型结构化

26、分析模型构成数据建模和对象描述功效建模和数据流图基本加工逻辑阐明行为建模（时序图）数据词典01:07:28第36页第36页面向数据流建模面向数据流建模是结构化需求分析办法之一采用自顶向下逐层分解，描绘满足用户要求软件模型（数据模型、功效模型、行为模型）表示：数据流图：描述系统处理过程数据字典：模型中数据信息集合状态转换图：描述系统对内部或外部事件响应行为模型01:07:28第37页第37页软件设计阶段基本目的是结构系统“怎么做”模型描述。“设计先于编码” 是软件工程“推迟实现”基本原则。软件系统设计是把软件需求“变换”为用于结构软件蓝图。“输入”是需求分析各种模型元素“输出”是软件设计模型和表

27、示软件设计目的是对将要实现软件系统体系结构、系统数据、系统模块间接口，以及所采用算法给出详尽描述。软件设计概述01:07:28第38页第38页软件设计概念总体设计，或称概要设计，或软件结构设计，或高层设计分析需求规格阐明模块划分，形成含有预定功效模块构成结构表示出模块间控制关系给出模块之间接口软件详细设计，也称(模块) 过程设计，或低层设计。设计模块细节拟定模块所需算法 和数据结构等编写所有代码设计测试和复审01:07:28第39页第39页软件结构设计过程 含系统设计和结构设计。系统设计拟定系统详细实现对象，结构设计拟定软件体系结构。软件结构设计环节:设计供选择方案选取合理方案推荐最佳方案功效

28、分解和设计软件结构数据库设计制定软件设计测试计划编制设计文档审查和复审软件设计过程01:07:28第40页第40页软件模块化设计模块是一个独立命名，拥有明拟定义输入、输出和特性程序实体。把一个大型软件系统所有功效，按照一定原则合理地划分为若干个模块，每个模块完毕一个特定子功效，所有这些模块以某种结构形式构成一个整体，这就是软件模块化设计（Modular Design）。软件模块化设计能够简化软件设计和实现，提升软件可理解性和可测试性，并使软件更容易得到维护。分解、抽象、逐步求精、信息隐蔽和模块独立性，是软件模块化设计指导思想。01:07:28第41页第41页软件系统模块化是指整个软件被划分成若

29、干单独命名和独立访问部分，称之为模块。每个模块完成一个子功效，把全部模块集成起来组成一个整体，能够完成指定功效，满足用户需求。把问题子问题分解与软件开发中系统子系统或系统模块对应起来，就能够把一个大而复杂软件系统划分成易于了解比较单纯模块结构。模块化能够使一个复杂大型程序能被人智力限制所管理，是软件应该具备最主要属性。实际上，每个程序都对应地有一个最适当模块数目，可使软件系统开发成本最小。模块划分目标： 进行功效分解，把复杂大功效划分成简朴小子功效，尽也许降低每个模块成本。尽也许使每个模块间接口不能太多，太多会使接口成本增加。兼顾二者可取得最正确划分状态，确保软件总成本最低。软件模块化01:0

30、7:28第42页第42页模块独立性模块独立性（Module Independence）是模块化、抽象、信息隐蔽等概念直接结果，也是判断模块化结构是否合理原则。模块独立性是指开发含有独立功效而和其它模块没有过多关联模块。模块独立性两大长处：独立模块由于分解了功效，简化了接口，使得软件比较容易开发；独立模块比较容易测试和维护。模块独立性由两个定性原则度量：耦合是模块之间互相连接紧密程度度量内聚是模块功效强度(一个模块内部各个元素彼此结合紧密程度)度量。模块独立性愈高，则块内联系越强，块间联系越弱。01:07:28第43页第43页概要设计概要设计也称总体设计，拟定软件结构以及各构成成份(子系统或模块

31、)之间互相关系。概要设计主要任务是：将系统划分成模块；决定每个模块功效；决定模块调用关系；决定模块界面，即模块间传递数据。概要设计实现方式：通过数据流图来拟定系统结构图，并且对这些结构图进行分析和细化。在概要设计阶段，结构化设计主要采用面向数据流设计办法。01:07:28第44页第44页详细设计详细设计就是在概要设计基础上决定如何详细实现各模块内部细节，直到对系统中每个模块给出足够详细过程描述。在编码实现阶段能够完全按照详细设计细节过程来映射到代码，最后实现整个系统。普通使用结构化程序设计工具来描述01:07:28第45页第45页细设计基本任务为每个模块进行详细算法设计为模块内数据结构进行设计

32、为数据结构进行物理设计，即拟定数据库物理结构其它设计：依据软件系统类型，还也许要进行下列设计： 代码设计输入/输出格式设计人机对话设计编写详细设计文档评审01:07:28第46页第46页面向对象概念面向对象是一个程序设计办法，或者说它是一个程序设计范型，其基本思想是使用对象、类、继承、封装、消息等基本概念来进行程序设计。面向对象办法学面向对象分析（OOA，Object-Oriented Analysis）是一个半形式化规格阐明技术。面向对象设计（OOD）面向对象实现(OOP)面向对象测试(OOT)01:07:28第47页第47页面向对象概念面向对象特性抽象性：强调实体本质、内在属性，忽略一些无

33、关紧要属性。类实现了对象数据（即状态）和行为抽象，是对象共性抽象。封装性：指全部软件部件内部都有明确范围以及清楚外部边界。每个软件部件都有友好界面接口，软件部件内部实现与外部可访问性分离。 共享性：面向对象技术在不同级别上促进了共享。面向对象分析(OOA，Object-Oriented Analysis)是一个半形式化规格说明技术。OOA是当前软件开发主流方法，是软件工程人才必须具备基础知识和必备能力。在进行系统业务调查后，按面向对象思想分析问题。01:07:28第48页第48页OOA与SA区别：OOA强调在系统调查资料基础上，针对OO办法所需要素材进行归类分析和整理，而SA强调对管理业务现实

34、状况和办法分析。 当前最流行OOA技术：OMT(Object Modeling Technology, 对象建模技术)：它从对象模型、动态模型和功效模型三个方面对系统进行建模，每个模型从一个侧面反应系统特性。Booch开发技术：Booch办法所采用对象模型要素是：封装、模块化、层次类型、并发。主要概念模型是类和对象、类和对象特性、类和对象之间关系。使用图形文档包括六种：类图、对象图、状态转换图、交互图、模块图和进程图。UML之前比较普及一个面向对象软件设计办法。面向对象概念01:07:28第49页第49页面向对象模型面向对象模型三种主流形式按照产生顺序排对象模型：定义“做什么”实体。它可表示系

35、统数据或对数据处理，它是数据流和语义数据模型结合。动态模型：要求在何种状态下，接受什么事件触发而“做什么”。它表示瞬间、行为化系统“控制”性质，并要求了对象模型中对象合法改变序列。功效模型：指明系统应当“做什么”。它直接反应用户对目的系统需求。01:07:28第50页第50页对象模型对象模型表示静态、结构化系统“数据”性质。描述是系统一个静态结构，是对模拟客观世界实体对象，以及对象彼此间关系映射。对象模型基本构成形式 = 类(包括其属性和行为) + 对象(类实例) + 类或对象之间关系。类名是一类对象抽象命名，其命名是否恰当对系统可理解性影响相称大。对象模型还必须表示类/对象之间结构关系。类/

36、对象之间关系普通可概括为关联、归纳/继承（泛化）、组合（汇集）三类。01:07:28第51页第51页动态模型动态模型表示瞬间、行为化系统“控制”性质，它要求了对象模型中对象合法改变序列。也能够说，动态模型是基于共享而互相联系一组状态集合。对象运营周期中阶段就是对象状态,对象状态是对对象属性一个抽象。对象之间互相触发/作用行为（称为事件），引起一系列状态改变。事件是引起对象状态转换控制信息。事件没有连续时间,是瞬间完毕。对象对事件响应，取决于接受该触发对象当初所处状态，其响应包括改变自己状态，或者是形成一个新触发行为（事件）。动态模型描绘了对象状态，触发状态转换事件，以及对象行为（对事件响应）。

37、01:07:28第52页第52页统一建模语言UML统一建模语言（UML，Unified Modeling Language）是一个基于面向对象可视化建模语言。UML用丰富图形符号隐含表示了模型元素语法，而用这些图形符号构成元模型表示语义，构成模型描述系统结构（或称为静态特性）以及行为（或称为动态特性）。UML模型元素：一类模型元素用于表示模型中某个概念，如类、对象、用例、结点、构件、包、接口等；另一类模型元素用于表示模型元素之间互相连接关系，主要相关联、泛化（表示普通与特殊关系）、依赖、汇集（表示整体与部分关系）等。01:07:28第53页第53页UML能够从不同视角为系统建模，形成不同视图。

38、视图是系统完整描述中一个抽象，代表该系统一个特定方面。每个视图由一组图组成，图包含强调系统某首先信息五类视图用例视图用于描述系统应该含有功效集， 强调从用户角度看到或需要系统功效，是对系统抽象表示。 逻辑视图用来展现系统静态或结构组件及特性。显示系统内部功效是怎样设计，利用系统静态结构和动态行为来刻划系统功效。 并发视图表达系统动态或行为特性。显示系统并发工作情况。 组件视图用来显示代码组件组织方式，描述了实现模块和它们之间依赖关系，表达了系统实现结构和行为特性 展开视图用来显示系统物理架构，即系统物理展开，表达了系统实现环境结构和行为特性。UML视图与图01:07:28第54页第54页面向对

39、象分析过程面向对象分析阶段主要任务是获取用户需求，并构建系统初步逻辑模型。用例建模：获取用户需求，构建用例模型。辨认外部用户场景分析构建活动图构建用例图领域建模：目的是建立系统概念模型。抽取领域对象构建领域模型构建初步交互模型01:07:28第55页第55页面向对象分析过程面向对象设计过程主要是对分析阶段建立对象模型或类模型和交互模型进行精化过程。精化类模型和对象模型交互行为建模设计类精化构建逻辑架构01:07:28第56页第56页用例驱动分析过程用例建模分析开发活动图开发泳道图用例着眼于为用户增长价值，提供了一个捕获功效需求系统且直观办法，可驱动整个开发过程。用例从某个特定参与者角度用简朴易

40、懂语言阐明一个特定使用场景。要开始开发用例，应列出特定参与者执行功效或者活动。用例模型帮助客户、用户和开发人员在如何使用系统方面达成共识。用例图描述部分用例模型，显示带有联系用例和参与者集合用例驱动分析01:07:28第57页第57页领域与业务建模领域模型能捕获语境中最主要对象模型，领域对象代表系统工作环境中存在事情或发生事件。领域有三种典型形式：业务对象，表示业务中可操作东西。比如订单、帐单、帐户和协议等。系统需要处理现实世界中对象和概念。如导弹、轮船、学籍、ATM、POS等。将要发生或已经发生事件。比如飞机起飞、午餐、休息、学籍籍点、取款、制造计划等。领域建模目的是理解和描述在领域语境中最主要类。01:07:28第58页第58页分析类分析类侧重于处理功效性需求，通过较高、非形式化层次职责类定义某行为分析类三种基本结构型：边界类：边界类用于建立系统与其参与者之间交互模型，经常代表对窗口、窗体、窗幕、通信接口、打印机接口、传感器、终端以及API等抽象。每个边界类至少应当与一个参与者相关，反之亦然。控制类：控制类代表协调、排序、事务处理以及其它对象控制，经惯用于封装与某个详细用例相关控制。控制类还能够用来表示复杂派生与演算，如业务逻辑。实体类：实体类用于对长期有效持久信息建模。大多数情况下，实体类是直接从业务对象模型中