软件工程7.ppt

软 件 工 程,1,第七章 面向对象技术,7.1 面向对象的概念7.2 面向对象的软件开发过程7.3 核心过程工作流,软 件 工 程,2,7.1 面向对象的概念,方法的唯一性 从生存期的一个阶段到下一个阶段的高度连续性，生存期后一阶段的成果只是前一阶段成果的修改和补充。系统结构的稳定性 系统的基本成分是对象，对象在软件开发和运行过程中是稳定的，经常变化的是功能。在面向对象系统中，功能是由对象中的操作和对象之间的消息序列来实现的，变更发生在对象内部。,软 件 工 程,3,1.面向对象开发模式,在过程性开发模式中优先考虑的是过程抽象，（即过程的逐步求精，但在使用者面前只呈现顶层的功能）；在面向对象开发模式中优先考虑的是实体（问题领域中的对象）。在面向对象开发模式中，把标识和模型化问题领域的主要实体做为系统开发的起点，主要考虑对象的行为而不是必须执行的一系列动作。,软 件 工 程,4,面向对象开发模式的特点,面向对象系统中的对象是数据抽象与过程抽象的综合。系统的状态保存在各个数据抽象的所定义的数据存储中。控制流包含在各个数据抽象中的操作内。在面向对象体系结构。消息从一个对象传送到另一个对象。算法被分布到各种实体中。通过执行消息传递和对象中的操作实现算法的功能。,软 件 工 程,5,软 件 工 程,6,2.什么是面向对象,Coad和Yourdon给出了一个定义：面向对象=对象+类+继承+通信如果一个软件系统是使用这样 4 个概念设计和实现的，则认为这个软件系统是面向对象的。一个面向对象的程序的每一成份应是对象，计算是通过新的对象的建立和对象之间的通信来执行的。,软 件 工 程,7,面向对象的特点,抽象性：对象的数据抽象和行为抽象；封装性：信息隐蔽；共享性：同一类中所有实例共享数据结构和行为特征；同一应用中所有实例通过继承共享数据结构和行为特征；不同应用中所有实例通过复用共享数据结构和行为特征,软 件 工 程,8,3.对象(object),对象是系统中用来描述客观事物的一个实体，是构成系统的一个基本单位，由一组属性和一组对属性进行操作的服务组成。属性一般只能通过执行对象的操作来改变。操作又称为方法或服务，它描述了对象执行的功能，若通过消息传递，还可以为其他对象使用。,软 件 工 程,9,计算机窗口中的三个多边形,软 件 工 程,10,表示多边形的三个对象,软 件 工 程,11,对象的分类,外部实体：与系统交换信息的外部设备、相关子系统、操作员或用户等；信息结构：问题领域中的概念实体，如信号、报表、显示信息等；需要记忆的事件：系统执行过程中产生并需要记忆的事件，如单击鼠标，击打键盘等；角色：与系统交互的人员所扮演的角色，如学生、教师、会计等；,软 件 工 程,12,组织机构：有关机构，如公司、部门、小组等；地点或位置：用做系统环境或问题上下文的场所、位置，如客户地址、收件人地址等；操作规程：如操作菜单、某种数据输入过程等。,软 件 工 程,13,4.类(class),把具有相同特征（属性）和行为（操作）的对象归在一起就形成了类(class)。类的定义包括一组数据属性和在数据上的一组合法操作。在一个类中，每个对象都是类的实例(Instance)，它们都可使用类中的函数。类定义了各个实例所共有的结构，使用类的构造函数，可以在创建该类的实例时初始化这个实例的状态（实例变量）。,软 件 工 程,14,由两个四边形对象导出一个类,软 件 工 程,15,Quadrilateral类的每个实例有相同的一组属性和操作。因此，类Quadrilateral提供了一个模板，表示了四边形对象。类可视为是一个抽象数据类型的实现。但把类看做是某种概念的模型更合适。建立类的实例时常常使用其他类的实例，它们提供了该类所需要的服务。用到的这些实例应当受到保护防止其他对象存取，包括同一个类的其他实例。,软 件 工 程,16,5.消息（Message）,消息是一个实例与另一个实例之间传递的信息，要求该实例执行类中定义的某个操作。消息的使用类似于函数调用，消息中指定了某一个实例，一个操作名和一个参数表(可能是空的)。接收消息的实例执行消息中指定的操作，并将形式参数与参数表中相应的值结合起来。消息有 4 类：,软 件 工 程,17,发送对象激活接收对象；发送对象传送信息给接收对象；发送对象询问接收对象；发送对象请求接收对象提供服务。,软 件 工 程,18,6.继承(Inheritance),如果某几个类之间具有共性的东西(信息结构和行为),抽取出来放在一个一般化类（泛化类）中，而将各个类的特有的东西放在特殊化类（特化类）中分别描述，则可建立起特化类对泛化类的继承。继承是使用已有的类定义做为基础建立新类的定义的技术。已有的类可当做基类来引用，则新类相应地可当做派生类来引用。,软 件 工 程,19,各特化类中的底盘、发动机、轮胎、驱动装置等可以作为共性集中到泛化类汽车类中。各个特化类可以从泛化类中继承共性，这样避免了重复。复用共同的描述，继承性往往被看作是软件复用的核心概念。,软 件 工 程,20,建立继承结构的好处：易编程、易理解、代码短,结构清晰易修改 共同部分只要在一处修改即可易增加新类 只须描述不同部分怎样建立一个好的继承层次类可以从父类继承，父类又可以从它的父类继承，形成多层次的继承结构。当增加一个新类时，不一定在最低层，可能需要插在中间层，这样可能需要调整原来的层次结构。,软 件 工 程,21,现要建立一个新类起重车。它的底盘、发动机、轮胎、驱动装置等都在已有类汽车中。关系如右图所示。新类是已有类的特殊情形。这时直接让起重车类作为汽车类的子类即可。,软 件 工 程,22,现要增加一个新类拖拉机。它的底盘、发动机等与汽车类不同，但驱动装置、轮胎等与汽车类相同。关系如下图所示。调整继承结构。建立一个新的一般的车辆类，把拖拉机与汽车类的共性放到车辆类中，拖拉机与汽车类都成为车辆类的子类。车辆是抽象类，相关操作到子类汽车找。,软 件 工 程,23,另一种情形是在已有类的基础上加入新类，使得新类成为已有类的泛化类。例如，已经存在三角形类，四边形类，想加入一个多边形类，并使之成为三角形和四边形类的泛化类。,软 件 工 程,24,多继承,如果一个类需要用到多个现有类的特征，可以从多个类中继承，称为多继承。例如退休教师是继承退休者和教师这两个类的某些特征或行为而得到的一个新类。,前三个情况主要是通过查找（应用领域)类库，找到可以原封不动地继承的类或可以通过调整继承层次结构继承的类。但如果在已有的继承层次中找不到可以继承的已有类，就从新开始完全独立地建立一个类。,软 件 工 程,25,7.多态性和动态绑定,对象互相通信，即一个对象发消息给另一个对象，执行某些行为或又发消息给另外的对象，从而执行系统的功能。,软 件 工 程,26,发送消息的对象可能不知道另一个对象的类型是什么。例如在C语言程序中使用命令 ClearInt()时要区分该命令适合一个整数，还是一个整数数组。但在C+情形，ClearInt()对两者都适用，它自己判断对象是哪个。这就是多态性(Polymorphism)。它意味着一个操作在不同类中可以有不同的实现方式。如 ClearInt()针对消息对象是 int array 还是int，其实现是不同的。,软 件 工 程,27,例如，想要在屏幕上画一系列多边形，多态性允许一个表的元素可以属于一组指定的类型而不仅仅是一个类型，可以认为这是一个类族。通过遍历这个表，发送给各个表元素以draw消息，画出所有的多边形。多态性的实现有 2 种：利用继承关系，把所有数据类型当作一个抽象数据类型的子类型。利用模板机制，把所有可能的数据类型用一个参数化的数据类型来代替。,软 件 工 程,28,动态绑定保证执行与对象 P 连接的操作。如果 P 是矩形类的实例，则执行与矩形连接的操作，而不用与四边形类或多边形类连接的操作。动态绑定把函数调用与目标代码块的连接延迟到运行时进行。这样，只有发送消息时才与接收消息实例的一个操作绑定。,软 件 工 程,29,7.2 Rational统一开发过程,软件开发项目多种多样，但都存在不同的不足或缺陷。导致软件项目“出局”的原因，总结起来，有以下几个方面：对于最终用户提出的要求理解不够精确；对需求变更采取的对策不适当；程序块之间不兼容；软件不易维护，不易扩充；,1.最佳软件开发实践,软 件 工 程,30,对项目中的严重缺陷发现得太迟；软件质量低劣；软件性能差到令人无法接受；开发组每个人按各自方式进行开发，当某人修改了部分软件，则很难与其他部分集成；一个不可靠的实现和发布过程。尽管不同项目失败的方式各不相同，但究其原因，可能是以下几方面的问题造成的：需求管理不规范；,软 件 工 程,31,沟通不通畅，沟通信息模糊或不精确；软件体系结构脆弱、不稳定；软件过度复杂；需求、设计与实现之间不一致；测试不够；对于项目状况的估计过于主观；未解决存在的风险；无法控制变化的产生和传播；自动控制不足。,软 件 工 程,32,为解决这些问题，需要以一种更好的、迭代的、可预测的方式开发软件产品，这就是软件开发中的最佳实践。最佳实践包括：迭代式软件开发；需求管理；基于构件的软件体系结构；建立软件可视化模型；不断验证软件质量；控制变更。,软 件 工 程,33,1)迭代式地开发软件,经典的软件开发过程模型是瀑布模型，它最大的问题是把风险留给了后面的阶段。要想清除早期阶段引入的故障需付出很大的代价。另一种是基于螺旋模型的迭代和增量的过程。,软 件 工 程,34,这种方法是一个连续地发现、创造和实现的过程。在生存期早期，可以及时发现和改正严重的需求理解错误；允许和鼓励用户反馈信息，以明确系统的真实需求；使开发人员重视项目中最关键问题，抓住可能导致项目真实风险的问题；不断迭代地测试可以给出项目状况的客观评价；尽早发现需求、设计和实现间的不一致；,软 件 工 程,35,2)需求管理,需求在整个软件项目生存期中是变化的。需求是系统必须达到的条件或性能。动态需求管理包括三项活动：获取、组织系统的功能和约束，并记入文档；估计需求的变化并评估它们的影响；跟踪、记录和权衡所做出的各种决策。项目的需求管理提供了一系列方案，用以解决软件开发中所遇到的问题。,软 件 工 程,36,它规定了一系列需求管理的原则性方法；人员之间的交流都建立在已定义的需求上；规定了需求的优先级，可对它们进行过滤和跟踪；对功能和性能可做出尽可能客观的评价；易于发现系统中的不一致性。,软 件 工 程,37,3)使用基于构件的软件体系结构,一个软件体系结构包括一系列重要决策：确定软件系统的组织；确定构成系统的结构元素及其接口；用结构元素之间的协作关系说明各个结构元素的行为；将这些结构元素及其行为组合为更大的子系统；依据软件体系结构风格约定，指导系统的构建：约定涉及元素和它们的接口、协作和组合。,软 件 工 程,38,基于构件建立软件体系结构提供了一系列方案，用以解决软件开发中所遇到的问题：使用构件可以创建有弹性的体系结构；模块化方法使得人们可以分别关注系统中容易变化的不同元素；通过使用标准化的框架（如 CORBA，EJB，COM+）和其他商品化的构件可以提供软件的可复用性；构件为软件配置管理提供了一个非常自然的基础。,软 件 工 程,39,4)建立软件的可视化模型,模型是现实的简化，它从特定的视角完整地描述一个系统。,模型,软 件 工 程,40,通过模型化，可将系统体系结构的结构和行为可视化，具体化。应用UML（统一建模语言），开发人员可以清楚地，无二义性地与其他人交流他们的想法和决定。可视化建模可以帮助开发人员提高管理软件复杂性的能力。通过迭代开发实践，还可以展示体系结构的变化，有助于人们评估这些变化，确保在每次迭代过程中协调模型与源代码的一致性。软件的可视化建模可以提供一系列方案，用以解决软件开发所遇到的问题：,软 件 工 程,41,通过用例和场景可以无二义性地详细说明系统的行为；通过模型可以无二义性地理解软件设计；可以发现软件体系结构中不灵活的地方；必要时可以隐藏某些细节；无二义性的设计易于揭示某些不一致性；好的应用程序从好的设计开始；可视化建模工具可以为 UML 建模提供支持。,软 件 工 程,42,5)不断地验证软件质量,在软件实施之后再查找和发现软件问题，比在早期就进行这项工作需多花10 到100 倍的费用。因此，必须从功能、可靠性、性能等方面不断对软件质量进行评估。验证系统功能，需要对每一个关键场景进行测试。场景描述了系统应实现的某一种行为。场景测试检测：哪些场景执行有问题，在什么地方出问题，出现什么问题（有缺陷或未实现）等，从而评估软件功能。,软 件 工 程,43,6)控制软件的变更,当软件开发在不同组、不同地点并行进行时，开发人员同时工作于多个迭代过程、发布版本、产品和平台上，如果没有严格的变更控制，开发过程就很容易陷入混乱。为使软件开发人员、开发组的活动和制品协调一致，必须建立管理软件变更的循环工作流，在迭代过程中，持续监控变更，动态地发现问题并及时反映。每次迭代过程结束时需建立和发布经过测试的基线，保证迭代过程与发布版本协调一致。,软 件 工 程,44,在每个版本元素之间和在多个平行版本元素之间保持可跟踪性，以便能够评估和动态管理变更造成的影响。控制软件的变更可以提供一系列方案，用以解决软件开发所遇到的问题：定义需求变更的工作流并在开发过程中反复使用这个工作流。建立变更请求报告，促进了人们的交流。变更中建立变更人员的专用工作空间，减少了平行工作的小组成员之间的相互干扰。,软 件 工 程,45,建立变更率统计，可客观度量和评价项目的状况。在变更专用工作空间中需包括全部涉及的制品，这样有利于保持一致性。可以评价和控制变更的产生和传播（影响）。可以在一个健壮的定制系统中维护变更。,软 件 工 程,46,2.Rational统一开发过程,软件开发过程的作用是：成为开发组活动顺序的向导。详细说明需要开发哪些制品？何时开发？指导每一个成员及整个开发组的工作。提供监控和度量项目产品和活动所依据的准则。如果没有一个良好定义的过程，开发组将各自为政。开发成功与否完全依赖个别优秀的人才，这不是能够长久的。,软 件 工 程,47,成熟的开发组织能够利用定义良好的开发过程，采用上述的最佳实践活动，以一种可预测的循环方式开发复杂的系统。这样，软件开发组织的能力能够保持稳定，并能随着新项目不断改进，从而提高整个软件开发的效能和生产率。Rational 统一开发过程正是建立在上述六项最佳实践活动的基础之上，目的是交付一个定义良好的过程。,软 件 工 程,48,1)什么是Rational统一过程,Rational 统一开发过程简称 RUP（Rational Unified Process），是一种软件工程过程。RUP描述了如何在软件开发组织中严格分配任务和职责的方法。其目标是：按照预先制定的时间计划和经费预算，开发高质量的软件产品，以满足最终用户的需要。RUP 是一个过程产品。Lee Osterweil 提出：软件过程也是软件。RUP 可以像任一软件工具那样设计，开发，交付和维护。,软 件 工 程,49,RUP有自己的过程框架。该框架的特点是：RUP是用例驱动的、以体系结构为核心的、迭代的增量的过程。RUP 采用二维的过程结构：过程的第一维（横轴）表明过程的生存期，它反映了过程被激活时的动态情况，用周期、阶段、迭代和里程碑表示。过程的第二维（纵轴）表明过程的静态状况，通过过程构件、活动、工作流、制品和工作人员描述过程。,软 件 工 程,50,初始,细化,构造,移交,阶 段,初始化,细化#1,细化#2,构造#1,构造#2,构造#3,移交#1,移交#2,迭 代,工作流,业务建模,需求,分析与设计,实现测试实施,配置和变更管理项目管理环境,沿时间轴的组织结构,沿内容轴的组织,软 件 工 程,51,2）过程的静态描述：过程模型,过程模型中的主要模型元素有 4 种：工作人员：谁做（who）活动：怎么做（how）制品：做什么（what）工作流：何时做（when）,用况实现,活动,工作人员,制品,软 件 工 程,52,(1)工作人员（Worker）,过程的中心概念是工作人员。工作人员不是指某一个人，而是指完成工作的角色。工作人员定义人们应履行的行为和职责。通常。用活动描述行为，用制品衡量职责。一个人可以扮演一个或多个角色。在过程中，可以是系统分析员、设计师、用例设计师、测试设计师等。,软 件 工 程,53,项目经理在计划项目和人员分配时根据每个人的技能安排每个人担当的角色。一个人可以担当几个工作人员；一个工作人员也可以由几个人担当。,软 件 工 程,54,(2)活动（Activity）,活动定义了工作人员所执行的工作。活动有明确的目的，通常是生产制品或更新制品（如模型、类或计划）。每一个活动都分配给特定的工作人员。为生成一个制品，可能会多次重复某些活动，特别是从一个迭代过程到下一个迭代过程，可以不断细化和扩展该制品。在面向对象方法中，把工作人员定义为对象，工作人员完成的活动就是对象执行的操作。,软 件 工 程,55,(3)制品（Artifact）,制品是过程生产、修改或使用的一种信息。制品可分为输入制品和输出制品。在面向对象设计中，制品被当作活动的参数。制品有多种可能的形式，如：模型:如用例模型或设计模型；模型元素:如类、用例或子系统；文档:如一个业务用例或体系结构文档；源代码；可执行文件。,软 件 工 程,56,(4)工作流（工作流程）,工作流用来描述能够生成有用结果的活动序列，用以描述工作人员之间的交互。一个工作流可以用顺序图、协作图或活动图来描述。RUP 的工作流由下列方式组织：,核心工作流 工作流细节 迭代计划,软 件 工 程,57,核心工作流,在 RUP 中共有 9 个核心过程工作流。它们将所有工作人员和活动进行逻辑分组。核心过程工作流分为 6 个核心工程工作流和 3 个核心支持工作流。核心工程工作流有：业务建模工作流、需求工作流、分析和设计工作流、实现工作流、测试工作流、实施工作流。核心支持工作流有：项目管理工作流、配置和变更管理工作流、环境工作流。,软 件 工 程,58,工作流细节,每个核心工作流覆盖多个领域。为了将工作流细化，RUP 用工作流细节描述与工作流联系紧密的一组特定的活动。工作流细节还要描述伴随的信息流，即活动的输入或输出制品，给出活动在不同制品之间是如何交互作用的。,在一个项目中这些核心工作流在每一次迭代中重复发生。在每次重新发生时，它们在具体内容上有所不同，与迭代的中心问题有关。,软 件 工 程,59,迭代计划,迭代计划根据某一迭代过程中要完成的典型活动，结合将要处理的问题，更加详细地描述过程。主要内容有：时间分配：迭代进度表；迭代内容：分配活动和工作人员：迭代期间完成哪些用例；识别技术风险并转化为用例，缓解策略；部分或完整地实现哪一个子系统。次要里程碑：达到预先制定的标准。,软 件 工 程,60,3）过程的动态描述：迭代开发,以往人们常采用顺序开发过程，即瀑布模型，其步骤为：完全理解要解决的问题，规定对目标软件的需求和约束，准确描述它们；设计一个能满足所有需求和约束的解决方案，仔细检验这个设计；使用最好的工程技术实现解决方案；验证实现结果是否满足规定的需求；交付产品。,软 件 工 程,61,但顺序开发过程有它的问题，主要表现为：需求和市场随着时间推移会发生变化。技术基础随着技术进步也会发生变化。软件设计不能保证一定是正确的。对于未知的项目，软件开发充满风险。软件开发时间长，每一个活动只进行一次，没有学习和自我提高的机会。开发过程过分强调确定的被认可的文档和冻结的基线，妨碍了以前阶段的反馈。不适于基于增量的开发。,软 件 工 程,62,解决方案是将一个大型项目分解为可连续应用瀑布模型的几个小部分。在对一部分进行需求分析和风险、设计、实现并确认之后，再对下一部分进行需求分析、设计、实现和确认。以此进行下去，直到整个项目完成。这就是迭代式开发。在RUP中，迭代过程分为几个阶段。,软 件 工 程,63,初始阶段（Inception）：确定最终产品的构想及其用例，定义项目范围。细化阶段（Elaboration）：计划需完成活动和资源，详细说明产品特性并设计软件体系结构。构造阶段（Construction）：构造整个产品，逐步完善视图、体系结构和计划，直到产品（完整的构想）已完全准备好交付给用户。移交阶段（Transition）：移交产品给用户。包括制造、交付、培训、支持及维护产品。,软 件 工 程,64,这 4 个阶段经历的时间是不同的。每个阶段时间的长短要具体情况具体分析。特定项目环境导致各阶段时间长短可能有很大不同。每个阶段最重要的是阶段目标和里程碑。典型的时间分配如下：,I：初始阶段 E：细化阶段 C：构造阶段 T：移交阶段,软 件 工 程,65,这 4 个阶段构成开发周期，周期结束时产生一代新的软件产品。软件产品产生于初始开发周期，随着重复执行同样的过程，软件发展到下一代产品，这一时期即为软件的进化周期。,软 件 工 程,66,用户需求的变更、基础技术的变化、竞争都可能激活新的进化周期。周期之间在时间上会有重叠。后一个周期的初始与细化阶段可以与前一个阶段的移交阶段可能同时进行。在各阶段内也包含有一个或几个迭代过程。,软 件 工 程,67,(1)初始阶段,目标 将一个好的想法发展为最终产品的一个构想，提出该产品的业务实例。确定项目的软件范围和边界条件，明确系统向它的用户提供的基本功能；识别系统的关键用例，即主要行为场景；给出一个试验性的软件体系结构，它是包含主要场景的系统大致轮廓；估计整个项目需要的成本和时间；评估风险，即分析不确定性的原因；,软 件 工 程,68,制品构想文档：有关项目核心需求、关键特性和主要限制的构想。用例模型调查：包括所有在此阶段可确定的用例和参与者。初期的项目术语。初始的业务用例：包括业务环境、是否成功的评价标准、经济预测。早期的风险评估。项目计划：表明阶段和迭代。,软 件 工 程,69,(2)细化阶段,目标说明该产品的绝大多数用例，并设计出系统的体系结构。分析问题领域，建立合理的体系结构并对其进行评审，然后设定基线；确定项目计划，评价项目最有可能出现的风险因素，为计划设定基线；体系结构表现为系统中各种模型的不同视图，合起来表示整个系统。其中包括了用例、分析、设计、实现、实施模型的视图。,软 件 工 程,70,制品用例模型（至少完成80%），定义在用例模型调查中识别出的所有用例，所有参与者，完成大部分用例描述。补充需求，包括非功能需求和与具体用例不相关的需求。软件体系结构描述，及可执行的体系结构原型。修改后的风险清单和业务用例。关于整个项目的开发计划，描述迭代过程和每个迭代过程的评价准则。,软 件 工 程,71,更新后的开发案例，详细描述将要用到的过程。初步的用户手册（可选）。,(3)构造阶段,目标 此阶段是一个制造过程，目标是开发整个系统，并确保产品可以开始提交给客户，使产品达到最初的运行能力。开发和集成构件特征和应用程序的特征，使之成为软件产品，并进行测试。,软 件 工 程,72,通过优化资源和减少返工与浪费，降低开发成本，提高产品质量。以最短时间生产一个实际可用的版本(alpha版本、Beta版本及其他测试版本)。制品在适当平台上集成的软件。用户手册对当前版本的描述。,软 件 工 程,73,(4)移交阶段,目标 将软件产品移交给用户群。如果用户在使用时发现了新问题，必须在纠正问题之后，建立产品的一个新版本。使产品达到用户可自我支持的程度。项目相关人员共同协作完成实施基线，并与构想的评价准则保持一致。以最快速度和最好效益达到最终产品效益。移交过程是个迭代的过程，包括Beta版本，普通可用版本，纠错版本，升级版本等。,软 件 工 程,74,3.用例驱动的过程,使用 Rational 统一过程，重点在于建模。通过模型，理解和明确要解决的问题，确定问题的解决方案。首先是对问题的建模，用以表达用户需求及系统约束。在这个模型建立起来之后，还要建立一系列模型来描述解决问题的方案。为此，必须保持这些模型的一致性。用例建模技术可以用为大多数项目相关人员理解的形式来表述问题。,软 件 工 程,75,1)基本概念,参与者定义了一组与系统有信息交互关系的人、事、物。它是用例的客户并与用例进行交互。一个参与者针对每一个与之通信的用例扮演一种角色。角色可以是人或外部系统。它定义了“系统的边界”。,(1)参与者(actor),软 件 工 程,76,用例是在与系统参与者交互时系统（或其他实体）能够执行的一系列动作的规格说明。一个用例是系统、子系统或模块的功能单位。用消息序列表示。这些消息表明了在系统与一个或多个与系统一起执行规定动作的外部交互者（即Actor）之间的交互。,Use Case,(2)用例(use case),软 件 工 程,77,用例是参与者使用系统的一种方法，可对某一特定的参与者产生一个可见的结果。用例的三个特性：每一用例受某个参与者直接或间接激活而开始执行；每一用例将产生执行结果传送给某个参与者；每一用例一定是系统中一个完整的功能。,软 件 工 程,78,参与者与用例的区别在于：参与者不在系统的控制之下，即它在系统的处理过程之外；而用例在系统的完全控制之下。用例处于系统内部，它们之间的接口外部不可见；而参与者和用例之间的接口外部是可见的。根据这些准则，划定系统的边界。边界外是参与者，系统之内是用例，把这些用一个用例图记录下来。,软 件 工 程,79,用例和参与者的事例 银行储户通过自动取款机（ATM）提款、转账或检查账户余额。用一组用例表达如下：用例的集合给出系统所有可能的方法，每一个用例代表系统提供给参与者的价值(value)。,软 件 工 程,80,(3)事件流（flow of events）,事件流描述了参与者与系统之间的动作序列。事件流用自然语言描述，或用问题领域的术语，以前后一致的方式描述。例如，用例“提款”的事件流可描述如下：,储户将卡插入ATM机，系统读取并验证卡上信息。系统提示输入个人标识号码PIN，储户输入PIN，系统进行验证。系统提示几种可能操作，储户选择“提款”。,软 件 工 程,81,系统提示取款数量，储户输入金额数量。系统询问账户种类，储户选择某种账户ID。（支票账户、储蓄存款账户、信用卡）系统与ATM网络交换信息，验证账户ID、个人标识PIN和检查账户上的剩余金额。系统提示储户取走卡，储户将卡取走。系统将现金提交给储户。系统恢复到提款前的状态，用例结束。用例事件流中存在不同的路径，会产生不同的价值和效果。,软 件 工 程,82,(4)场景（scenario）,每一个用例有一个用例类。用例类的实例是一个特定的事件流或一个特定的路径。用例类简称为用例，用例实例简称为场景。在过程中使用场景的目的是提取或标定一个单独的贯穿于用例的动作序列或“线索”。在项目的早期寻找用例时，可以从场景出发，逐步纳入更多的相关事件流，直到形成为大家认可的较为完善的用例。在测试时，可借助场景定义测试用例。,软 件 工 程,83,(5)用例模型,将整个系统或子系统的所有用例，以及与之交互的参与者集合起来构成系统的用例模型。用例模型给出系统预期功能模型和系统上下文环境模型。它成为开发人员和用户之间的契约。用例模型的目的是确保系统能处理所有的功能性需求。在做分析时可不考虑系统的并发性，所有场景可以同时运行而不会出问题。但在设计时，应考虑并确保能正确处理所有非功能性需求，包括并发性。,软 件 工 程,84,2)用例驱动的过程,RUP是用例驱动的过程，是将用户需求转化为软件系统的一系列活动的集合。所谓“用例驱动”指开发过程是基于用例，从一个工作流向下一个工作流，逐步前进的。开发初期，开发人员使用用例获取用户需求，建立用例模型，描述系统的全部功能。基于用例模型，开发人员创建一系列实现这些用例的分析模型、设计模型和实现模型。测试人员测试实现确保系统正确实现了用例。,软 件 工 程,85,(1)用例的识别,用例是系统向它的参与者提供的有价值的功能。通过识别各种参与者的要求，就能够捕获他们所需完成工作的用例。开发人员还可以研究系统需要提供给参与者的有价值的结果，考虑为提供这些结果所需的动作序列，对其分组，也能找出用例。例如，当储户在使用ATM机提款时，当插入银行卡，输入PIN后，机器提供的价值有：提取现金、转移资金、存入资金、查询余额。这些就是ATM机的用例。,软 件 工 程,86,(2)用例的演进,用例开发时，可以先给出用例的概要（初始阶段），再研究它的细节（细化阶段），逐步进行开发。在细化阶段结束时，要完成必要用例的详细描述。评价用例详细程度的标准是：不同项目相关人员对于用例所表达的意义是否有不同的理解。设计人员和测试人员对于用例描述的详细程度是否满意。,软 件 工 程,87,(3)在过程中使用用例,用例模型是需求工作流的结果。此时，用例的作用是从用户的角度捕获系统的功能。用例成为在用户和系统开发人员之间进行沟通的工具。在分析和设计阶段，用例贯穿于分析和设计过程中。通过对象间的交互，可描述在设计模型中是如何执行用例的。通过浏览用例，还可发现对象和类。用例模型可保证在系统设计中描述所有需要的行为。,软 件 工 程,88,在实现阶段，设计模型就是实现规格说明。因此，可根据设计来实现用例，深入了解系统的动态特性，确定在哪里可以优化系统性能。在测试阶段，用例构成测试用例和测试规程的基础，可利用用例验证系统的行为。在项目管理中，用例用来定义迭代的内容，估算工作量和时间进度。在实施中，使用用例包来定义系统变量，计划阶段性实施。在原型设计与用户界面设计中也需要用例。,软 件 工 程,89,在业务建模中，也用到用例。但业务模型描述的是高层业务，而不仅仅是一个系统。因此，业务用例模型描述了高层业务过程，并提供了表达系统用例的上下文环境。,软 件 工 程,90,4.以体系结构为核心的过程,传统的体系结构采用方框和箭头描述。这样的体系结构的形成过程复杂，不易扩展。当需要扩展系统时，不得不重新改造系统。因此，使用了不好的软件体系结构（加上不成熟的过程），是导致项目失败的原因之一。现代软件开发机构必须考虑如何能够控制软件的复杂性，并能通过跨越系统族实现大规模的复用，使用已经实现的构件来建立新的系统。,软 件 工 程,91,1）体系结构的表示,体系结构设计是软件设计的一部分。它不仅涉及系统的组织结构，而且涉及系统的行为，即在结合点和接口处会有什么事件发生。定义体系结构还要考虑系统的外部上下文环境，即操作环境（涉及最终用户）、开发环境（涉及开发系统的组织）。不同的人员，对于体系结构的侧重点不同：系统分析员 他们通过体系结构组织需求，明确表达需求，以及技术约束与风险。,软 件 工 程,92,设计师 他们通过使用体系结构理解设计原则和自己设计的边界。架构师 他们通过体系结构确定如何扩展和实现软件复用。项目经理 他们利用体系结构组织开发队伍，制定开发计划。子承包商或其他开发组织 他们通过体系结构了解自己承担开发部分的边界，了解如何与系统衔接。最终用户 他们通过使用体系结构，可以从更高层次上直观认识自己购买的产品。,软 件 工 程,93,因为不同的项目相关人员关心体系结构的不同部分，因此一个完整的体系结构描述是多角度的，并且是可视化的。在软件密集型系统的体系结构中，可以为不同的目的设计不同的蓝图（Blueprint）：表述系统的逻辑结构。组织系统的功能。表达系统的并发性。描述在底层平台上软件的物理分布。,软 件 工 程,94,2）以体系结构为中心的过程,用例的选择不是孤立的，它与软件的体系结构是密切相关的。软件体系结构的作用与建筑的体系结构类似。对于一个建筑，可以从框架结构、供热、上下水、供电、天然气、其他服务管线等不同角度来考察它。使得施工人员在施工前就能全面了解这个建筑。软件的体系结构也从不同角度描述了即将构造的系统，包括系统的静态特征和动态特征。,软 件 工 程,95,软件体系结构是根据业务需要逐步开发出来的。受到用户和其他项目相关人员的影响，并在用例中得到反映。每一种产品都有功能和表现形式两个方面。用例就是功能，体系结构就是表现形式。在开发过程中，必须兼顾功能和表现形式，做出适当权衡，才能得到好的产品。因此，用例和体系结构必须在迭代中并行演进。为了找到可以演进的体系结构，设计师必须从全面了解系统的主要功能（即主要用例）入手。,软 件 工 程,96,7.3 核心过程工作流,核心工作流包括业务建模、需求、分析与设计、实现、测试、实施、项目管理、配置与变更管理、环境等九个工作流。在整个软件开发过程从项目开始到结束，并不是只执行一遍核心工作流序列，而是在每一次迭代中都要执行一次，除了业务建模工作流之外。如果在开发过程的四个阶段需要七次迭代，则需要执行这些工作流七次。,软 件 工 程,97,1.业务建模工作流,对于开发电子商务系统的组织，最核心的工作是建立业务模型。业务模型描述了业务过程的本质和执行情形，业务建模的目标是：理解系统的组织(目标组织)和动态特性；理解在组织结构中的问题，明确改进方向；确保客户、最终用户和开发人员对系统的组织结构有统一的理解；获取对待开发系统的系统需求。,软 件 工 程,98,事实上，业务建模过程是为实现计算体系结构创建整体计划的过程。在基于业务目标的上下文环境中建立框架：业务对象模型：业务或业务功能所需数据体系结构的框架。业务用例模型：为某种业务目的在数据体系结构中完成数据变换的软件体系结构，包括人员作用和尚未自动化的业务规程。技术基础设施：支持应用和数据的硬件/软件组织，包括计算机、网络、通信链路、存储技术以及支持这些技术的体系结构。,软 件 工 程,99,工作流,业务建模工作流分为两个阶段：评估业务状态：这是一个迭代过程，目的是评定系统要实施的组织的状态。产生的制品是目标组织评估和业务构想。建立业务模型：在业务评估基础上，选择某一种业务建模场景，建立业务模型。业务建模的场景：场景1：组织图 建立描述组织及其过程的图示，以理解应用系统的需求。,软 件 工 程,100,场景2：领域建模 从业务出发为应用系统的信息建立模型，不考虑业务工作流。此时的领域模型和模型中的业务实体是业务对象模型的一个子集。场景3：一个业务多个系统 多个软件工程项目需要相同的业务时，可创建一个业务模型作为这些项目的输入。业务模型用于寻找功能需求，或作为应用系统族体系结构的输入。场景4：普通业务建模 创建可供多个组织使用的软件系统。模型可帮助理解和管理组织使用该软件的各种方法。,软 件 工 程,101,场景5：新的业务 为开发一个新的业务系统建立模型。建模的目的是识别系统需求，确定新的业务的特性。场景6：修改已有业务 即业务过程再设计。它通常分为以下几个阶段：设想新的业务、分离已有的要修改的业务设计、创建新的业务设计、集成新的业务设计。在场景3、场景4和场景6的情形，为了改进或重新设计某个已有的业务，必须先对当前业务建模，再对新业务建模。,软 件 工 程,102,软 件 工 程,103,2.需求工作流,当开发人员在开发一个新系统时，必须首先捕获需求，了解需要建立什么样的处理。这比编码要困难得多。需求工作流的目标是：定义系统功能及用户界面，使客户了解系统的功能，开发人员了解系统的需求，为项目预算及计划提供基础。定义系统边界。需求获取的结果可用Use Case模型表达。,软 件 工 程,104,为系统开发成本和时间估算提供依据。定义系统用户界面，主要关注于用户需求和目标。为了达到这些目标，需求工作流描述了：如何定义系统构想，并将这个构想转化为用例模型。使用该用例模型和补充规格说明定义详细的系统软件需求。如何利用需求特性帮助管理系统范围和需求变更。,软 件 工 程,105,1)什么是需求,需求可定义为系统必须满足的条件或具备的能力。需求可分为功能性需求和非功能性需求。功能性需求描述了系统应完成的工作。一般通过详细说明系统的输入和期望输出来描述系统的行为。非功能需求描述系统除功能性需求