1、软件工程实践,软件工程理念、方法与工具在项目中的应用,日程,关于一个项目的探讨 软件工程概述 案例分析：在项目中实践软件工程 规范软件开发,系统分析,分析需求用例建模及分析 定义需求需求文档 需求评审需求基线 问题跟踪过程 需求管理 建立需求 需求跟踪 需求度量 计划迭代,系统分析建模,帮助开发团队理解系统任务 尽早澄清系统及软件需求 建立与技术无关的需求模型,帮助开发人员理解需求 系统维护,尽早控制项目规模 减少需求变更,统一建模语言UML简介,UML是一种图形化的语言，用于对软件系统的产品进行 描述 可视化 构造 文档化,UML的发展历程,UML的来源,对UML做出贡献的公司,Aonix
2、Colorado State University Computer Associates Concept Five Data Access EDS Enea Data Hewlett-Packard IBM I-Logix InLine Software Intellicorp Kabira Technologies Klasse Objecten Lockheed Martin,Microsoft ObjecTime Oracle Ptech OAO Technology Solutions Rational Software Reich SAP Softeam Sterling Soft
3、ware Sun Taskon Telelogic Unisys ,UML的特点(1),语义丰富的可视化建模语言 统一了Booch、OMT等许多对象建模语言 经过实践检验 解决当前的软件开发问题 系统分布、并发、系统扩展等 可灵活地应用于任何软件开发过程 良好的可扩展性,UML的特点(2),定义了从分析到设计到实现的无缝映射 定义了丰富的和一致的符号 便于交流 辅助发现遗漏和冲突 支持各种规模的分析和设计 与过程无关 与实现语言无关,UML图与模型,静态应用结构： 类图：Class Diagram 对象图：Object Diagram 构件图：Component Diagram 部署图：Dep
4、loyment Diagram 动态应用行为： 用例图：Use Case Diagram 时序图：Sequence Diagram 活动图：Activity Diagram 协作图：Collaboration Diagram 状态图：Statechart Diagram 应用组织和管理： 包：Package 子系统：Subsystem 模型：Model,用例建模系统需求定义,从需求到用例,用例的来源 系统说明/问题陈述文档 问题域相关的文献 与问题域专家的会谈纪录 关于问题域的知识 现有系统 ,从IDEF0到Use Case,用例模型,用例模型用于描述相关系统功能及其环境的模型。 用例模型用于
5、用户和开发团队之间的交流。 用例模型用于需求、分析、设计、实现和测试中。 用例模型组成： 描述 Use Case 包 Actor和Use Case 关系 Use Case图,一个Use Case是系统所执 行的并向特定的Actor产生 可观察的结果的一系列动作。,Actor表示与系统发生交互的任何事物。,概念：Actor和Use Case,Actor,Use-Case,Actor,Actor处于系统的外部，代表系统用户扮演的角色。 Actor可以主动地与系统交换信息。 Actor也可以被动地接收信息。 Actor可以是一个人、硬件设备或另外的系统。,寻找Actors：有用的问题,谁对特定的需求
6、感兴趣? 系统将在企业的哪个部分被使用? 谁将向系统提供信息，使用信息，删除信息? 谁将使用这个功能? 谁将负责支持或维护系统? 系统是否使用外部资源? 用例需要哪些Actors? 一个Actor是否扮演多个角色? 是否有几个Actor扮演共同的角色?,Actors的实例,U,s,e,-,C,a,s,e,M,o,d,e,l,Actor,Use Case,一个用户作为多个Actors,系统边界,Use Case,Use Case表示Actor与系统之间的对话。 一个用例由一个Actor启动以调用系统的特定的功能。 一个用例是完整的有意义的事件流。 所有用例一起构成了可能的使用系统的方式。,寻找U
7、se Cases：有用的问题,这个Actor的任务是什么? 这个Actor将创建、存储、修改、删除或读取系统中的信息吗？ 什么Use Case将创建、存储、修改、删除或读取这些信息？ 对于突发的、外部的变化，Actor需要通知系统吗？ 当系统中发生某些事件时，需要通知Actor吗？ 系统是否为某项业务提供了正确的行为？ 什么Use Case被用来支持和维护系统？ 所有的功能需求都能够被这些Use Case执行吗？,用例建模示例及产品演示,用例描述,用例文档 类型： Brief：简单描述 Casual：随意的 Fully dressed：完整的 概念： 事件流 场景 扩展,Use Case文档模
8、板,用例文档示例及产品演示,用例驱动的软件开发,用例模型,测试,设计,项目估算,项目计划,风险管理,开发,测试需求 测试计划 测试用例 ,从需求到实现,Use Case 模型,Class 模型,行为 模型,构件 模型,业务 模型,Class 模型,行为 模型,部署 模型,用户需求,系统需求,分析模型,设计模型,实现模型,用例分析：系统的结构和行为,Use Case 模型,Class 模型,行为 模型,用例分析,找类MVC,系统行为对象交互,职责分配,描述,描述,描述,实现 模型,找类,什么是对象?,非正式的定义：一个对象代表了一个现实的或虚构的实体 物理实体 概念实体 软件实体,化学过程,较正
9、式的定义,对象是应用中具有明显边界和含义的概念、抽象或事物 对象有三个重要的属性： 状态 行为 标识,对象有状态,对象的状态是对象当前存在的可能条件 对象的状态会随时变化 对象的状态通常由其一系列的特性（属性）、属性的值及对象与其它对象之间的连接实现,对象有行为,行为确定对象行动和反应 行为定义对象对其它对象请求的反应 对象可见行为由一套它能够进行反应的（对象能够执行）消息来规定,对象有标识,每个对象都有唯一的标识，即使其状态有可能与其它对象一样,什么是类?,在很多领域中都有很多对象 类是对一组对象的描述。这些对象具有共同的属性、共同的行为（操作）、与其它对象的共同的联系（关联和聚合），以及共
10、同的语义 对象是类的实例 类是一种抽象，在其中： 强调相似的特征 忽略其它的特征 抽象的手段可以帮助我们处理事物的复杂性,对象,类,类和对象之间的联系,类是对象的抽象定义 在类中定义了每个对象的结构和行为 它提供了创建对象的模板 对象能被集合在类中，是类的实例,代数 101 艺术史 化学 西班牙语 101,发现类的指南,类应当捕捉一个且仅仅一个关键的抽象 不好的抽象：学生类（学生信息和本学期学生的课程表） 好的抽象：将学生和学生课程表分为两个类,命名类,类的命名最好使用单个名词来表现其抽象 命名困难往往暗示着抽象定义不当 该名称应该能从本领域的专业词汇表中直接获得,命名类的风格指导,风格指导应
11、该规定类的命名约定 风格指导举例 类命名使用单个名词 类命名开始以大写字母开头 不使用下划线 当名字由多个单词聚合而成时，每个单词的开头字母大写 例如：Student、Professor、BillingSystem,注意 “什么” 而忽略 “怎样”,定义类语义,类命名之后，必须为类加一个简要描述 主要描述类的目的而不是实施 类命名和描述是模型字典的基础,a + b = 10,类的表示法,类被表示为分为若干部分的长方形,什么是属性?,属性是类实例的数据定义 属性没有行为它们不是对象 属性名称是简单的名词或名词短语 在类中其命名是唯一的 每个属性必须有一个清楚简练的定义,操作应该执行简单、连贯的功
12、能,什么是操作?,类体现了一系列责任，它们决定了类中对象的行为 类通过其操作完成这些责任 操作是可以由对象或有效操作请求执行的服务,类从何而来？,我创建了Use Case模型，可是怎样从Use Case中找到类呢？,应用MVC模式 分析问题域，创建概念模型 应用类责任协作卡,应用MVC模式,MVC模式： “modelviewcontroller” 候选类 实体类 边界类 控制类,Movie_Copy,Store,Customer,Movie,实体类,描述持久的信息和行为： 反映现实现象 系统完成内部任务所需的信息 通常由Actor提供属性值 行为独立于环境,边界类,描述系统环境和内部工作之间的
13、通信 典型的边界类： 窗口(用户界面) 通信协议 (系统间接口) 设备接口,控制类,描述一个或多个Use Case的控制行为 控制行为： 创建、初始化或删除受控对象 控制受控对象活动的顺序和协作 控制受控对象的并发行为 通常是无形的对象的实现,构造型Stereotypes,构造型： 建模元素的一种新的类型， 用于扩展元模型语义 基于元模型中现存的类或类型 每个类最多有一个构造型 常用的构造型 Boundary class Entity class Control class,分析问题域,概念模型：表示现实世界中的事物 IDEF1x：数据建模方法 逻辑模型 IDEF1x建模过程： ERD：Ent
14、ity-Relationship Diagram KB：Key-Based FA：Fully-Attributes,从数据模型到概念模型,数据模型和术语表： 实体 属性 关系,类、属性、关系,概念模型,UML,类责任协作卡,Class-Responsibility-Collaboration (CRC) cards Ward Cunningham and Kent Beck ,at OOPSLA ,in 1989 CRC卡： 类名称和描述 类的责任 类的内部知识 类提供的服务 责任的协作者（类）,CRC卡,类名,责任,协作者,CRC卡实例,CRC模型,Use Case 模型,UI 原型,CRC
15、 模型,Class 模型,CRC 建模步骤,Put together the CRC modeling team. Organize the modeling room. Do some brainstorming. Explain the CRC modeling technique. Iteratively perform the step of CRC modeling. Perform use-case scenario testing.,CRC 建模团队,问题域专家 Business Domain Experts（BDEs） 召集人 记录员 观察员,Organize the room
16、,头脑风暴Brainstorm,CRC 建模,解释CRC建模技术 迭代的CRC建模步骤： 寻找类 寻找责任 定义协作者 定义Use Case,CRC建模寻找类,与系统交互的任何事物Actors 客户？ 系统生成的报表报表类 系统用户界面界面类 创建CRC卡 简要描述类 类名为单数名词,CRC建模寻找责任,类应当知道什么？ 类应当做什么？ 如果已经定义可了责任，应当将其分配给哪个类？（GRASP模式） 类之间应当相互协作。,CRC建模定义协作者,当一个类需要它没有的信息。 当一个类要修改它没有的信息。 一个协作通常总有一个发起者。 增加新的协作者。,CRC建模,定义Use Case 摆放CRC卡
17、 有协作的类靠近 “busy”类放在中央 发现类之间的关联,Use Case场景测试,CRC卡方法的优缺点,优点： 问题域专家进行分析 增强用户参与 打破沟通障碍 简单，直截了当 低成本，方便 与原型相结合 直接导出类图,缺点： 开发者的问题 用户的问题 CRC卡的限制,CRC建模技巧,提前制定日程 显著地显示CRC的定义 使用问题域中的术语 低技术含量 结合原型 时间 管理层的支持 将CRC建模纳入系统开发生命周期中 只由一线人员参与,系统行为分析,系统行为：对系统动作的描述。 系统行为分析： 系统行为：系统时序图 用于显示Use Case的一个特定的场景 外部Actor生成的事件 事件的顺
18、序 系统之间的事件 对象交互：时序图 用于显示Use Case的一个特定的场景 外部Actor生成的事件 事件的顺序 对象之间的交互,对象交互,交互图,交互图： 时序图 协作图,概念：时序图,按时间顺序显示对象之间的交互。 交互图显示： 对象 交换消息的顺序 时序图中包含： 对象和“生命线” 消息 控制交点（Activation）,时序图中命名对象,对象被画成长方形，在名称上有下划线 对象“生命线”通过下拉虚线来表示,Course,:Course,c1:Course,类,实例 （匿名对象）,实例 （命名对象）,时序图,时序图,时序图示例及产品演示,系统逻辑结构建模,关系,整个系统包含很多类和对
19、象 对象间通过相互合作完成了对象系统行为 通过关系完成协作 分析阶段中有两种重要的关系 关联（Association） 聚合（Aggregation）,关联（Associations）,关联（association）是 类之间双向的语义连接 这暗示着相关类的对象间有一个连接 关联在类图中表示为连接相关类的一条线 数据既能单向又能双向流动,导航（Navigation）,关联是双方向的关系 任给一个RegistrationManager的实例，与 Course 对象之间都有关系 任给一个Course的实例，与 RegistrationManager对象之间都有关系,关联的命名,为清楚起见，要为关联
20、（ association ）命名 其名称作为关联线的标签，放在两个类中间 关联的名称通常是动词或动词短语,关联的角色（Roles）,角色表示一个类与其它类关联时的目标或能力 角色名称一般是名词或名词短语 角色名称放在关联线上，靠近它修饰的类 关联的一端或两端都可能有角色名称,关联（Associations）的多重性,多重性是一个类的多个实例与其它类的1个实例相关 对于每个关联，可以有两种多重性：在关联的每一端都有一个 例如， 在Course与扮演教师角色的Person相关时 对每个Person 的实例，有多个 (例如：0或多个) Courses 被教 对每个 Course的实例，只有一个Pe
21、rson是教师,多重性指示器（ Indicators）,关联的每一端都有一个多重性指示器 指出关系中参与对象的数量,图中说明了什么?,Course,Teacher,1,0*,多重性意味着什么?,多重性回答了两个问题 关联是必不可少的还是可选的? 一个实例与其它实例连接的最少和最多数目,A course may have many pre-requisites A course may be a pre-requisite for many other courses,Pre-requisite,0*,0*,自反关联（Reflexive Associations）,在反身关联（ reflexiv
22、e association）中，同一个类中的对象相互发生了关系 表明同一个类中的多个对象以某种方式相互协作,关联类（Association Classes）,我们希望对一个学生所有课程的成绩进行跟踪 学生与课程之间是多对多的关系 我们把成绩属性放在哪里呢?,关联类（Association Classes）（续）,成绩属性不能放在Course类中，因为 有很多（潜在的）连接与多个Student对象相连 成绩属性不能放在 Student类中，因为 有很多（潜在的）连接与多个Course 对象相连 因此，属性真正属于每个Student-Course连接 关联类（association class）
23、可以用来保留连接信息,画关联类（Association Classes）,用类图标创建关联类 用虚线把创建的类图标与关联线连接起来 关联类中可能包括多种关联属性 每个关联只允许有一个关联类,关联类和多重性,关联类常用于多对多的关联中 如果关联任一端的多重性是“对一” 属性可以放在具有多重性一侧的类中，或 仍然使用关联类,给 Department对象一个 Employee ID 的值，只有一个Professor对象与之对应,给 Department 对象一个Title的值，有一组 Professor 对象与之对应,限定符,限定符是一个或一组属性，其值用来区分通过关联与其它对象相关的一组对象,约束
24、,一个约是一个表达式，代表一些必须得到满足的条件 约束表示在大括号中,聚合（Aggregation）,聚合（Aggregation）是一种特殊的关联（association），在其中，整体与其一部分相关 聚合被称作”部分“包含关系 聚合表示为带有菱形头的关联，菱形头紧挨着表示聚合（整体）的类 多重性的表示与关联中多重性的表示方式相同,组成聚合Composition,Fig. 3-45, UML Notation Guide,组成聚合Composition (contd),Fig. 3-45, UML Notation Guide,一个ProductPart对象是 由零或多个 ProductPa
25、rt 对象“组成”,自反聚合（Reflexive Aggregates）,同样可以有反身聚合 经典的原料类型清单问题 这表明了一种递归的关系,关联或聚合?,如果两个对象具有紧密的 “整体部分”关系 这是聚合关系 如果两个对象通常被认为是独立的，尽管它们常常发生连接 这是关联关系,RegistrationForm “talks” to ScheduleFormScheduleForm “talks” to RegistrationManager,aform : Registration,Form,aform : Schedule,Form,theMgr : Registration,Manage
26、r,发现关联和聚合,可以检查方案来确定两个类之间是否存在关系 只有当“了解”彼此时，两个对象才能沟通 关联（ Associations ）和/或聚合（ aggregations ）提供了沟通的途径,关联或聚合?,继承,继承表示一个类从其它类中获得结构和/或行为 继承表示子类（ subclass ）从父类（ superclasses ）继承时抽象的层次 单继承（single inheritance）：子类只从一个父类继承 多继承（multiple inheritance）：子类从不只一个父类中继承 继承通常被称为“is a”或“kind of”的关联,父类 （Superclass）,子类 （Su
27、bclass）,继承关系 （Inheritance relationship ）,StudentInfo,RegistrationUserInfo,画继承层次,如何获得继承?,子类继承它的父类的： 属性 操作 关联 子类可能： 增加附加的属性、操作、关联 重新定义继承操作（慎重使用！）,Truck有三种属性： licenseNumber weight tonnage,继承属性,属性在继承结构的最高一层定义 所有的子类的实例能够继承这些属性 每个子类可以增加继承的属性,truck 有三种属性 licenseNumber weight tonnage 和两种操作 register() getTax
28、(),继承操作,操作在继承结构的最高一层定义 所有子类的实例能继承这些操作 每个子类可以增加或重新定义继承的属性,继承关联,关联同样可以继承，并在继承结构的最高一层定义 所有的子类的实例能够继承这些关联 每个子类都可以分享附加的关联,类的通用化（Generalization）,通用化（Generalization） 提供了一种创建父类的能力（压缩结构和/或将共同的行为到一些父类中） 通用化过程 在若干类中确定相似的结构/行为 创建父类来压缩共同的结构/行为 原来的类被称为新父类的子类 父类是从子类中抽象出来的,通用化实例,递增的抽象,类的特殊化（ Specialization ）,特殊化提供了
29、创建子类的能力，表现为详细描述了子类增加或更新的结构或行为 特殊化过程 注意一些有特殊化结构或行为的实例 创建子类，将特殊化实例归组 子类有比父类更少的抽象,递减的抽象,特殊化实例,继承层次（Inheritance Hierarchies）,通用化和特殊化都使用在开发继承层次中 分析时， 关键提取（例如，类）的继承层次必须被确定 设计时，继承层次定义为： 增加重用 合并执行类 合并可利用的类库,在继承级别的类应有同级别的抽象,抽象级别（Levels of Abstraction）,问题与讨论,使用包组织模型,包是将元素聚合成组的通用机制 随着对use cases和场景的逐个分析，产生的类的数目
30、不断增加 类能被组成包 使侍开发的模型能够被组织起来 包表示为带标签的文件夹,包之间的关系,包之间通过依赖关系相互联系 如果一个包中类要求与另一个包中的类“交流”，那么在包一级就应该添加依赖关系 方案图和类图被用来决定包的关系（ package relationships ）,依赖,supplier 包发生变化, Client package 必须重新编译并测试。 Client 包不能被独立地重用，因为它依赖于 supplier 包。 应当避免循环依赖。,循环依赖,Changed to,类图示例及产品演示,需求与项目开发,需求,制定项目计划,项目跟踪和监控,变更控制过程,构造过程,测试过程,系
31、统设计过程,相关标准对需求管理的要求,CMM 二级 需求必须形成文档 需求应当作为基线，必须受控 团队成员必须接受需求管理的培训 建立衡量需求状态的信息 三级 采用系统的方法分析需求 需求、设计、编码、测试都能回溯到相应的源 在需求变更实施之前进行影响分析 跟踪所有的需求变更 ISO9000 完整、无歧义的需求集 建立需求的责任分配给各小组的成员 建立同意和批准对需求变更的方法和过程 尽量避免对需求的误解 建立过程，对需求讨论的结果进行记录和评审,组织需求的目的,建立完整、结构清晰的需求，以便： 最小化需求的数量 理解大量信息 检测遗漏和重复 消除冲突 管理迭代 拒绝劣质的需求 评估需求 跨项
32、目复用,需求组织的问题,不合适的层次 差的定义 缺乏结构 缺乏控制 没有完成准则 ,IEEE标准的SRS的内容,介绍 目的 范围 定义、简称和缩写 参考 概述 总体描述 产品投影 产品功能 用户特征 限制 假设和依赖 详细需求 附录 索引,IEEE std 830-1998 : Recommended Practice for Software Requirements Specifications,SRS的本质,关于在特定环境中执行特定功能的特定产品的说明。 可能由客户、供应者或双方共同完成。 SRS作者应解决的基本问题： 功能 外部接口 性能 属性 影响到实现的设计限制,SRS的环境,SR
33、S在项目计划中的地位和作用。 SRS应声明系统与软件部分的接口 SRS应当与系统需求相一致 SRS应当： 正确定义所有软件需求 不应描述任何设计和实现细节 不应对软件施加额外的限制,IEEE：好的SRS的特征,正确 无歧义 完整 一致 优先级（重要性和稳定性） 可验证 可修改 可跟踪,需求评审,正规需求评审的目的,需求文档是否正确描述了预期的系统行为和特征？,需求文档是否是完整和高质量的？,需求能否成为系统设计、编码和测试提供了基础？,所有人对需求的理解是否一致？,需求评审中的角色,作者 需求的创建或维护者 读者 评审者 管理者 组织、协调 记录者,问题跟踪过程,变更鉴别 （变更提交者）,CR
34、已被审批,变更请求（CR） （CR、PR报告）,提交变更/ 接到授权,分析变更（冲突， 能力，花费等）,CR及分析文档交 由CCB进行审批,CCB进行审批,CR已被拒绝,CR已被延迟,CR交给团队实施,从配置库中 检出需变更的项,对变更后的项 进行单元测试,发行软件新版本,通知变更提交者 被拒绝的理由,文档记录延迟的理由,对变更后的项 进行复审和测试 （系统和集成测试）,已变更的项提 升到新的基线中， 变更包含在新版本中,需求基线,基线： 一个配置项在其生存周期的某个特定时间，被正式标明、固定并经正式批准的一个版本 用作进一步开发的基础 只有通过正式的变更控制才能加以更改 需求基线： 在项目开
35、发周期中经过正式评审并批准的需求文档 作为设计的基础,问题与讨论,需求管理,需求建立 需求跟踪 影响分析 需求变更控制,需求跟踪,目标：记录各种信息之间的关系，例如： 系统需求和用户需求 架构设计和系统需求 确认测试和用户需求 促进不同形式的分析 影响分析：那些会受到需求变更的影响？ 跟踪分析：此项需求的目的是什么？ 覆盖分析： 是否所有需求都被满足？ 是否所有功能都是必须的？（需求镀金）,需求跟踪,跟踪需求到设计、代码和测试。,需求跟踪,进行不同形式的分析 影响分析：那些会受到需求变更的影响？ 跟踪分析：此项需求的目的是什么？ 覆盖分析： 是否所有需求都被满足？ 是否所有功能都是必须的？（需
36、求镀金）,影响分析,用户需求,系统需求,设计说明,标准,确认测试,单元测试,系统测试,测试,测试,测试,限制,满足,满足,如果用户 需求变更?,跟踪分析,为什么?,用户需求,系统需求,设计说明,标准,确认测试,单元测试,系统测试,测试,测试,测试,限制,满足,满足,用户需求,系统需求,设计说明,标准,确认测试,单元测试,系统测试,测试,测试,测试,限制,满足,满足,覆盖分析, 已经完成？,跟踪其他信息,项目计划：跟踪需求到任务 设计决策：跟踪需求到设计选择 风险：跟踪需求到风险 问题：从问题回溯到需求,需求跟踪过程,建立需求跟踪策略： 选择跟踪链 选择跟踪矩阵 确定跟踪范围 制定跟踪规范 确定
37、责任 培训 建立跟踪 更新和维护跟踪矩阵,需求跟踪的作用,需求审核 影响分析 系统维护 项目跟踪 系统重建 复用 减小风险 测试,跟踪联系链的建立,需求变更的原因,系统的复杂性 系统内部或系统之间的交互 不良的需求 业务和计划的改变 技术的变化 法律、政策的变化 客户或用户改变了主意 开发人员的对需求的修改,需求变更的后果,允许需求随意变更 项目失败！,需求变更管理,需求变更管理是在项目的软件开发过程中，在需求基线建立后，当需求发生变更时，对需求变更进行控制和管理的过程。,变更控制流程,提交 变更,影响 分析,评估 变更,实施 变更,分派 人员,验证 变更,拒绝 变更,推迟 变更,取消 变更,CCB,影响 分析 报告,变更 请求 表格,变更请求,编号 简要描述 影响 状态 日期,变更级别和种类,变更级别 Minor 变更 Major 变更 变更种类 用户变更 设计变更 功能变更 性能变更,影响分析和评估,分析变更的影响 标识工作产品（需求） 评估 定量评估变更 重新评估项目风险 估计工作量和日程,验证和监控变更,验证 监控 项目计划中的“buffer” 跟踪变更的累计影响 累计影响 ？Buffer,用例与迭代开发周期,基于用例的需求管理 迭代开发计划 管理风险,示例,需求管理示例及产品演示 迭代计划示例 配置控制示例,问题与讨论,
