软件架构设计

lpf1005

贡献于2011-04-03

字数:0 关键词: 软件架构

1 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 软件架构文档设计 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 议题 z 软件配置管理 z 软件架构模版设计 2 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 SCM工作指南 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 4 议程 z 配置管理的基本概念 z 配置项标识 z 配置库目录结构 3 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 5 配置管理 (1)ISO 9000-3 :1997 配置管理是一个管理学科,它对配置项(包括软件项)的开发和支持生存期给与 技术上的和管理上的指导。配置管理的应用取决于项目的规模、复杂程度和风险大 小。 (2) W.Babich 的解释 软件配置管理能协调软件开发,使混乱减少到最小。软件配置管理是一种标识、 组织和控制修改的技术,目的是最有效的提高生产率。 (3) GB/T 11457 :1995《软件工程术语》国家标准 A.表示和确定系统中配置项的过程,在系统整个生存期内控制这些配置项的投放和更动 ,记录并报告配置的状态和更动要求,验证配置项的完整性和正确性。 B.对下列工作进行技术和行动指导与监督的一套规范: ——对配置项的功能特性和物理特性进行标识和文件编制工作; ——控制这些特性的更动情况; ——记录并报告这些更动进行的处理和实现的状态。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 为什么需要配置管理 忽视软件配置管理可能导致的混乱现象: • 发错了版本 • 安装后不工作 • 异地不能正常工作 • 已经解决的缺陷过后又出现错误 • 开发人员把产品拿出去出售赢利 • 找不到最新修改了的源程序 • 找不到编程序的人 4 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 SCM的主要职责(1) 变更控制 配置项标识 配置状态报告 工作产品的完整性、 一致性、可追踪性 配置审计 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 SCM的主要职责(2) z 配置项 • 受配置管理控制和管理的基本单位。配置管理工作都是围绕配置项来进行。 z 配置标识 • 要进行配置标识,首先必须明确项目生命周期内所要产生的工作产品,然后 确定工作产品的命名和标识规则。总体原则是方便在配置管理工具中进行检 索和让项目组成员容易记住标识规则,同时确保在组织一级的标识规则一致 性。 z 变更管理 • 变更管理是项目管理的一个重点和难点,涉及的范围很广。实施高效的变更 管理至少应该包括二个部分,一是定义合理变更管理流程,一是采用自动化 工具来支持。在具体的实践中,应该对变更进行分类和分层,建立处理不同 变更的变更控制委员会(CCB)构成策略,既能保证项目组成员有一定的自主 权又不耽误高层经理对关键问题的把握。 5 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 9 SCM的主要职责(3) z 报告配置状态 • 报告配置状态的目的是向项目所有成员提供基线内容和状态、基线变更信息 ,也是实现资源共享的前提。此外,在项目生命周期中通过对配置项的变更 数据统计分析,有利于评估项目风险,有效控制项目的执行。报告的方式可 以多种多样,如Email,但应该把握好时机:变更请求被批准时;基线版本发 生变化时;项目组任何需要的时候。 z 配置审核 • 配置审核包括两方面的内容:配置管理活动审核及基线审核。配置管理活动 审核确保项目组成员所有配置管理活动遵循批准的软件配置管理方针和规程 ,比如检入(Check in)/检出(Check Out)的频度,工作产品成熟度提升 原则等。实施基线审核,保证基线化软件工作产品的完整性和一致性,并且 满足其功能要求。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 10 确定配置项 1、 系统规格说明 2、 软件项目计划 3、 软件需求规格说明书 a.图形分析模型 b.处理规格说明 c.原型 d.数学规格说明 4. 初步用户手册 5. 设计规格说明书 a.数据设计描述 b.体系结构设计描述 c.模块设计描述 d.接口设计描述 e.对象描述(采用面向对象技术时 ) 6. 源代码清单 7、 测试规格说明 a.测试计划和步骤 b.测试用例和记录的结果 8、操作和安装手册 9、 可执行程序 a.模块可执行代码 b.连接的模块 10、数据库描述 a.模式和文件结构 b.初始内容 11、联机用户手册 12、维护文档 a.软件问题报告 b.维护请求 c.工程变更指令 13.软件工程标准和规程 6 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 11 配置项标识 z 配置标识是软件生命周期中划分选择各类配置项、定义配置项的种 类、为它们分配标识符的过程。配置项标识的重要内容就是对配置 项进行标识和命名。 z 原则 • 唯一性 • 可追溯性 • 与同类配置项不同的信息,应纳入标识:这是为了便于区分、查找 • 同类配置项的标识方法统一 • 容易记忆 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 12 文档标识方法(1) z 配置项的相关标识信息 • 组名 • 项目名 • 文档内容 • 版本号 • 文档撰写时间 • 文档撰写作者 7 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 13 文档标识方法(2) z 标识项目信息 命名方式:[项目编号+文档名称] 例如:RDMIS_需求规格说明书 适用于:需求规格说明书、概要设计说明书、详细设计说明书、测试计划等等 z 标识版本变化 版本变化不通过文档命名来标识,对于基线文档,在CVS中是通过tag来标识。并 且,在文档的头信息中必须注明文档的版本号。 命名方式:[文档名称] 例如:RDMIS_概要设计说明书 适用于有版本变化的文档。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 14 文档标识方法(3) z 标识文档撰写时间 命名方式:[文档名称+撰写时间] 例如:RDMIS项目会议记录_20040708 适用于:会议记录、项目周报、工作周报等等 z 标识文档作者 命名方式:[文档名称+人员名称] 例如:项目周报_李平_20041227 适用于:项目周报、工作周报、年终工作总结等等 z 标识子系统或者模块名称 命名方式:[项目编号+子系统名称+文档名称] 例如:RDMIS_绩效考评_详细设计说明书 适用于:子系统详细设计说明书、系统模块设计说明书等等 8 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 15 文档标识方法(4) z 文档首页可以包括这些信息:项目名、文档名、文档作者、本文档 的版本更新历史、版本号、日期、修改的页码等。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 16 程序标识信息 z 每个源程序的首部应包括的信息为:功能描述 、创建日期、作者、版本号。 9 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 17 版本号 z 形式:主版本号.从版本号.维护版本号 z 主版本号 • 对系统作重大调整,在功能和性能上有大的变化时主版本号增加。第一次版 本号和第二次版本号为零。版本号升级由项目组长/室主任决定。 z 从版本号 • 与上一版本相比,对系统功能或性能进行了少量的增加或修改,从版本号增 加,主版本号不变。版本号升级由项目组长决定。 z 维护版本号 • 与上一版本相比,修改了小量系统bug,维护版本号增加,主版本号和从版本 号不变。版本号升级由项目组长决定。 z 通常来说,通过软件系统测试后系统版本号变为V1.0,软件系统第一次发布时版本 号为V1.0.0,从版本号和维护版本号均为0。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 18 CVS辅助标识方法 10 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 19 版本的演变 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 20 配置库的作用 • 记录与配置相关的所有信息 • 利用库中的信息可评价变更的后果 • 可利用库中的信息查询,例如: • 那些客户已提取了某个特定的系统版本? • 运行一个给定的系统版本需要什么硬件和系统的哪些版本? • 一个系统到目前已生成了多少版本,何时生成的? • 如果某一特定的构件变更了,会影响到系统的那些版本? • 一个特定的版本曾提出过那几个变更请求? • 一个特定的版本有多少已报告的错误? 11 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 21 三库 (1)开发库: 存放开发过程中需要保留的各种信息,供项目组成员使用。 (2)基线库: 在软件开发的某个阶段工作结束时,将工作产品存入或将有 关的信息存入。 (3)产品库: 在开发的软件产品完成系统测试之后,作为最终产品存入库 内,等待交付用户或现场安装。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 22 配置库目录结构 12 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 23 配置库使用说明(1) z 放入正确的位置,正确标识 • 因为CVS工具本身的问题,如果你将文件放在错误的位置,或者命名 不规范,SCM进行位置移动或者修改文件名称的时候,会造成历史版 本的丢失,想要找回历史版本很不容易,给配置管理造成一定的工作 量。 • 所以请大家在进行文件入库时,注意放入正确的位置,并且正确命名 ,以免造成历史版本丢失。 z 及时提交、更新 • 如果习惯将自己的工作产品放在个人目录下,请及时提交或者 更新到服务器上,让相关人员能够看到最新的文件 • 养成良好的工作习惯,每次要对某个文件进行修改时,请首先 UPDATE这个文件,从服务器上更新最新版本,以免在旧版本基 础上修改,造成冲突,无法提交。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 24 配置库使用说明(2) z 提交规范 • 文件提交到服务器上时,有“Enter the log message”,请大家一定要填写,主要填写几个方面 的内容:修改的目的,修改的主要内容(段落或者 函数名称),修改可能造成的影响。 • 尤其是进入编码和测试阶段,要求每个文件的提交 必须有log message。请大家注意! 13 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 25 提交规范 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 26 软件架构模版设计 z 指导原则 z 标准模版 14 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 27 体系结构设计 z 体系结构设计原则 • 文学中有科学,音乐中有数学,漫画中有现代数学的 拓扑学。漫画家可以“几笔”就把一个人画出来,不管 怎么美化或丑化,就是活像。为什么?因为那“几笔” 不是别的,而是拓扑学中的特征不变量,这是事物最 本质的东西。 • 体系结构是指软件系统的基本和主体的形态,也就是 软件系统中“最本质”的东西。一个软件系统的体系结 构设计得好不好,可以用“合适性、结构稳定性、可扩 展性、可复用性”这些特征量来评估。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 28 合适性:即体系结构是否适合于软件的“功能性需 求”和“非功能性需求”。 z 设计师可以充分发挥主观能动性,根据需求的特征,通过推理和归 纳的方法设计出合适的体系结构。经验不丰富的设计师往往把注意 力集中在“功能性需求”而疏忽了“非功能性需求”,殊不知后者恰恰 是最能体现设计水平的地方。 z 高水平的设计师高就高在“设计出恰好满足客户需求的软件,并且 使开发方和客户方获取最大的利益,而不是不惜代价设计出最先进 的软件。(以设计住宅为例)… z 对于软件系统而言,能够满足需求的设计方案可能有很多种,究竟 该选哪一种?此时商业目标是决策依据,即选择能够为开发方和客 户方带来最大利益的那个设计方案。大部分软件开发人员天生有使 用新技术的倾向,而这种倾向对开发商业产品而言可能是不利的, 切记切记。 15 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 29 结构稳定性 • 当前中国有几句流行的至理名言:“稳定压倒一切”、“发 展是硬道理”。发展的前提条件是稳定,社会如此,开 发软件产品也是如此。 • 体系结构一旦设计完成,应当在一定的时间内保持稳定 不变,只有这样才能使后续工作顺利开展。如果体系结 构经常变动,那么建筑在体系结构之上的用户界面、数 据库、模块、数据结构等等也跟着经常变动,用“树倒 猢狲散”来比喻很恰当,这将导致项目发生混乱。 • 高水平的设计师应当能够分析需求文档,判断出哪些需 求是稳定不变的,哪些需求是可能变动的。于是根据那 些稳定不变的需求设计体系结构,而根据那些可变的需 求设计软件的“可扩展性”。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 30 可扩展性 z 可扩展性是指软件扩展新功能的容易程度。可扩展性越好,表示软件 适应“变化”的能力越强。可扩展性越来越重要,这是由现代软件的商 业模式决定的: • 社会的商业越发达,需求变化就越快。 • 现代软件产品通常采用“增量开发模式”,开发商不断地推出软件产品的 新版本,从而不断地获取增值利润。 • 稳定性和可扩展性之间存在辨证的关系:如果系统不可扩展的话,那么 就没有发展前途,所以不能只关心稳定性而忽视可扩展性;而软件系统 “可扩展”的前提条件是“保持结构稳定”,否则软件难以按计划开发出来 ,稳定性是使系统能够持续发展的基础。所以稳定性和可扩展性都是体 系结构设计的要素。 • 如果每次变化都导致体系结构发生大的变动,那简直就是“伤筋动骨”, 这样的体系结构无疑是败笔之作。(例如房屋装修) 16 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 31 可复用性 z 复用就是指“重复利用已经存在的东西”。被复用的对象可以是有形的 物体,也可以是无形的知识财富。复用不是人类懒惰的表现而是智 慧的表现。因为人类总是在继承了前人的成果,不断加以利用、改 进或创新后才会进步。 z 复用的有利于提高产品的质量、提高生产率和降低成本。由经验可 知,通常在一个新系统中,大部分的内容是成熟的,只有小部分内 容是创新的。一般地可以相信成熟的东西总是比较可靠的(即具有 高质量),而大量成熟的工作可以通过复用来快速实现(即具有高 生产率)。勤劳并且聪明的人们应该把大部分的时间用在小比例的 创新工作上,而把小部分的时间用在大比例的成熟工作中,这样才 能把工作做得又快又好。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 32 z 复用的意义很容易理解,人们也乐意复用以前的成果, 但是前提条件是该成果具有比较好的可复用性。可复用 性是指成果被复用的容易程度。 z 可复用性是设计出来的,而不是偶然碰到的。要使体系 结构具有良好的可复用性,设计师应当分析应用域的共 性问题,然后设计出一种通用的体系结构模式,这样的 体系结构才可以被复用。 17 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 33 体系结构设计流程 • 体系结构设计流程:6个步骤 • 《体系结构设计报告》模板见word文档

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 20 金币 [ 分享文档获得金币 ] 1 人已下载

下载文档

相关文档