设为首页 | 加入收藏夹

八文网 - 汇聚八方文档 - 做最优秀的免费文档下载网站

软件工程

文档类型：

Microsoft PowerPoint PPT 演示文稿文档大小：596.5KB

第九章软件工程本章首先简要介绍软件工程学科形成与发展,软件工程学的基本概念,学科的构成,特征以及与其它学科的关系.其次介绍软件工程方法,软件工程过程和软件描述语言等内容.最后较详细地介绍软件开发的需求,分析,设计,实现,测试5项主要工作.其目的在于使读者了解软件工程学科的概貌、熟悉软件开发的主要工作,并掌握软件开发的基本方法.
9.1 软件工程概述
9.2 软件开发方法
9.3 软件过程
9.4 软件建模语言
9.5 软件开发
9.6 习题和思考题
9.1软件工程概述
9.1.1 软件工程学科的形成与发展
9.1.2 软件工程的概念
9.1.3 软件工程学科的基本内容
9.1.4 软件工程学科的特点及与其它学科的关系自从计算机诞生以来,软件工程学科走过了一段曲折的历程.直到60年代,软件的概念才初步形成,软件的应用领域逐步扩大,软件开发中的诸多问题开始暴露,出现了严重制约软件发展的软件危机.在此基础上,提出了软件工程的概念,软件开发工程化逐步受到重视.70年代是软件工程学科奠基、形成,发展和应用的时期.软件工程学科的基本思想,概念和方法都是在这个阶段提出的,但还没有构成完整的学科体系.到了80年代,软件开发的相关技术得到迅速发展,软件应用向深度和广度发展,软件的规模和范围不断增大,并由独立系统向开放,互连,集成的一体化系统发展,软件产业化的速度加快、软件体系结构受到重视,软件开发环境逐步成熟.到了90年代,软件工程取得了突出进展.在这一时期,一方面软件工程的环境与技术得到了迅速发展,可视化技术,CS模式,WWW技术等已经成为现代软件工程的主流技术;另一方面,面向对象方法趋于统一.在OMT,Booch,Use cases等方法的基础上,形成了统一建模语言UML(Unified Modeling Language)和统一软件开发过程,软件工程开始步入规范化和工程化的时代.
软件工程(software engineering)的概念是于1968年在北大西洋公约组织举行的一次学术会议上首次提出来的.经过几十年的发展,软件工程已经成为一门独立的学科,称为软件工程学(software engineering science).它是应用计算机、数学,管理学的原理,运用工程化的理论、方法和技术,研究和指导软件开发和演化的一门交叉学科.同时,它还充分考虑软件的自有特性,从而达到提高软件开发效率,降级成本,保证质量之目的.
软件工程是一个年轻的学科,到目前为止,对软件工程学科的构成和基本内容还没有形成统一认识.根据软件工程研究的对象和任务,软件工程学科如图9.1所示、由软件工程原理,软件工程方法,软件工程技术,软件工程管理,软件工程度量,软件工程环境、软件工程应用等分支学科构成.
1.软件工程原理
2.软件工程方法
3.软件工程技术
4.软件工程管理_软件工程原理软件工程方法软件工程技术软件工程管理软件工程度量软件工程环境软件工程应用软件工程图9.1 软件工程学科构成
5.软件工程质量
6.软件工程环境
7.软件工程应用软件工程原理是软件工程学科所遵循的基本规律和原则.它包含软件工程学基础、软件工程学科中的共性规律,以及软件工程学科应遵循的基本原则.
软件工程方法指软件工程中所采用的方式,步骤,技术,工具和途径,是软件工程学科的核心.从广义上讲,软件工程方法包括软件开发方法,软件管理方法,软件度量方法,软件环境等、如果不细分,软件工程方法亦指软件开发方法.
软件工程技术是指从事软件开发所采用的手段和技法,主要包括软件开发技术,软件演化技术,软件管理技术,软件环境技术,软件度量技术,软件应用技术以及与软件相关的其它技术.
软件开发技术主要包括软件分型技术,软件构成技术,软件描述技术,软件规划技术,需求分析技术,软件建模技术,软件设计技术,软件编程技术,软件调试技术,软件集成技术等.软件演化技术是指软件运行和在维护等环节中所采用的技术.软件管理技术主要包括软件项目管理技术,软件获取过程管理技术,软件供应过程管理技术,软件开发过程管理技术,软件运作过程管理技术,软件维护过程管理技术,软件支持过程管理技术等.软件环境技术指软件开发和运行所需的工具和环境以及辅助软件开发的工具和环境等相关技术.软件度量技术包括软件定额技术,预算技术,决算技术,软件的效率,质量,性能度量,软件的结构,复杂度,算法度量技术等.软件相关技术是指在软件开发过程中所采用的相关技术,比如程序设计技术,可视化技术,客户机服务器技术,图像识别技术,条形码输入技术,语音识别技术,决策模型技术等.
管理在软件工程中起着重要作用,大量实践证明,中大型软件开发成功的关键不仅是方法和技术,而更重要是管理.因此,软件工程的组织和管理自然地成为软件工程学科的一项基本内容.它需要运用管理学,行为科学,道德,法律等学科的内容、探讨软件工程管理的规律.软件开发涉及到过程,人员,经费、材料,文档等多种要素,通过对这些要素进行有效的组织,计划,配置,控制,监督,有序有效地进行软件开发.
软件管理包括项目管理,过程管理,维护管理,人员管理,经费管理,进度管理,文档管理等.
5.软件工程度量度量是通过一套反映工程对象属性的指标或规则,对工程对象的内容和效果进行描述和评价.度量必须有一套能够全面,公允、客观反映工程对象属性和内在规律的指标体系和规则,只有通过度量,才能对工程对象的效果进行优劣评价.软件度量包括软件费用度量,工作量度量,生产效率度量,质量度量,性能度量,算法度量,结构和复杂性度量等;软件度量工作还包括定额编制,软件预算,软件决算等.
由于软件工程的发展历史短、需要研究和探讨的问题又很多,加之软件又比其它工程对象复杂,所以软件的度量水平还很低.到目前为止,还没有形成软件度量的指标体系.这也是造成软件过程难以预测,软件质量难以评价的主要原因.
软件不象其它产品和设备能够独立存在和工作,软件的开发和运行必须依附于软件环境.软件环境由计算机硬件,通信网络,支撑软件等要素构成.软件的依附性决定了人们在软件开发过程中、必须考虑软件环境以及软件环境对软件开发的制约和影响.
软件工程应用主要研究如何有效地把软件工程原理,方法,技术应用到软件开发和维护过程中去,以有效地提高软件开发效率和质量.
除了以上七个分支学科之外,软件工程的学科还包括软件工程经济学和软件工程标准规范等内容.
软件工程分属于计算机科学技术中的软件学科,它运用计算机科学与技术以及相关学科的概念和原理,研究软件开发和维护过程的内在规律,使软件开发工程化.
软件工程是建立在多学科基础上的综合性,交叉学科,与相关学科存在着广泛地联系.软件工程首先运用工程学的原理和方法来指导软件开发过程,以形成完整的工程体系;软件工程还运用到数学的理论和方法,与系统工程存在着密切的联系;软件工程还要运用心理学,行为科学和管理学的理论和方法,指导软件过程的管理,以提高软件的质量和效率.
9.1.4 软件工程学科的特点及与其他学科的关系软件作为一种社会产品有其经济价值,因此还需要运用经济学的原理和方法,进行社会,市场和经济分析.
系统性,工程化,综合性,交叉性,实践性,发展性是软件工程学科的基本特点.
软件工程作为一个年轻的学科,它的概念,理论、内容、方法,技术还处于不断发展和完善的过程中.较之于机械,化学,纺织等传统工程,软件工程学科的完备,规范和成熟的程度还有很大距离,所以是一门正在发展的学科.
软件开发方法包括软件开发过程,软件描述语言、软件开发工具,软件开发技术等内容.软件开发方法在很大程度上决定着软件开发的成败与优劣,是软件工程学科的核心.
在几十年软件工程的探索和实践过程中、较有影响的软件开发方法有结构化法,JSD法,原型法以及面向对象法.
9.2.1 软件开发方法的分类
9.2.2 结构化方法
9.2.3 JSD方法
9.2.4 原型法
9.2.5 面向对象法软件开发方法的分类有多种方式.首先从层次上,可分为基础方法和一般方法.基础方法是指在软件开发过程中人们分析和解决问题的基础方法,主要包括分析,综合,关联、抽象,模型,分类,系统,集成等;一般方法是建立在基础方法之上,适应于软件开发工作的方法体系,主要有结构化法,面向数据结构法,原型法和面向对象法等.
从适应范围,可分为局部方法和全局方法.局部方法仅仅适应于软件开发周期某一个或某几个阶段,全局方法覆盖软件开发的全过程.
从开发风范上,可分为自顶向下和自底向上的方法.自顶向下法遵循由粗到细,从总体到局部的开发.自底向上法则是按照由局部到总体,由细节到框架的一类开发方法.大部分软件开发并不单独使用某一种、而是两者相结合,但以某一种为主.
根据方法的严格性,可把软件工程方法分为形式化方法和非形式化方法.形式化方法是对软件需求,过程和要素采用形式化描述.非形式化方法强调软件开发的工程性,缺乏严密地形式化描述和推演论证.
从方法的面向,可分为面向功能法,面向数据法,面向对象法和面向其它处理对象法.面向功能法是把系统的功能作为分析,设计和实现的主线,结构化设计法属于该类.面向数据法是从数据及其结构入手,进行软件开发,JSD是典型的面向数据结构的方法.面向对象法是以客观事物和主观概念为对象.
另外,根据人工介入的程度,可分为自动化法,半自动化法和手工法.根据方法的过渡方式,还可分为过程型方法和迭代型方法.过程型法严格划分工作阶段和步骤,并按阶段和步骤进行软件开发.迭代型法则是螺旋式的开发方式,先根据需求构造一个初步的系统原型,在原型的基础上通过多次迭代过程完成开发工作.
结构化方法(structured mothod)是60年代末在结构化程序设计的基础上发展起来的,遵循系统工程的思想,充分考虑用户的需求,突出功能特征、按照软件生命周期严格划分工作阶段,强调软件各部分之间的结构及关系的一类开发软件的全局方法.结构化方法由结构化分析(SA),结构化设计(SD)和结构化编程(SP)三部分构成.
结构化分析是其中的第一个环节,它主要是运用结构化分析方法和工具,研究现行系统的业务管理过程和新系统的需求,通过综合系统目标,用户要求,考虑系统的背景和环境、以及资金能力和技术因素,通过客观,认真,全面地分析,确定出合理可行的系统需求,并提出新系统的逻辑方案(也叫系统逻辑模型),编写出系统说明书.系统说明书经过审查之后,提供给设计阶段,作为结构化设计的依据.
结构化分析遵从瀑布模型,所运用的工具是数据流图和数据字典.用数据流图描述数据的传输,加工处理;数据流图既作为现行系统数据加工处理的描述工具,同时又是新系统逻辑模型的描述工具.
结构化设计认为软件系统是由多个具有相互联系的模块组成,模块是系统的基本构件.结构化设计的基本工作就是确定构成系统的模块,各模块之间的联系以及每一个模块的功能,算法和流程.所以,结构化设计也被称为模块化设计.结构化设计包括总体设计和详细设计两个层次的工作.总体设计需要确定构成系统的所有模块以及各模块之间的关系,并用系统结构图来描述系统的总体结构,总体设计也称为结构设计.
详细设计则需要深入到各个模块内部,设计模块的数据结构和处理逻辑,详细设计也被称为模块设计,一般用伪码、判定树,判定表等工具描述其内部逻辑.设计工作的依据是系统的逻辑模型,在设计过程中把系统的数据流图转变成结构图,并根据数据流图中的各个加工,来设计各模块的内部数据结构和处理流程.
结构化编程是利用结构化程序设计方法,把设计的各个模块利用程序设计语言编写出来,并对编写的程序进行模块调试和集成调试,最后形成用户所需要的软件系统.
Jackson在1972年提出了面向数据结构的程序设计方法.该方法的基本思想是在开发软件时,先设计符合结构化规范的软件的数据结构,然后把数据结构转换成与之相应的程序结构,最后根据程序结构编写出程序.
Jackson系统开发方法(JSD,Jackson system development method)是在Jackson的面向数据结构的程序设计方法的基础上发展而来的,是一种面向软件开发全过程的系统化开发方法.它从客观现实中提取各种客观实体,并确定各实体的活动以及实体与各种活动之间联系,生成反映客观问题的进程模型.再在进程模型的基础上,增加系统功能,确定时序关系,最后实现所设计的系统.JSD方法可划分为建模,设计和实现三个阶段,共包括实体活动分析,实体结构分析,建立进程模型,确定系统功能,确定系统时序,系统实现等6个步骤.
原型法也称为快速原型法,其基本思想是在自动化或半自动化原型生成环境的支持下,根据用户的初步需求,通过原型生成环境、快速生成一个系统模型,这个模型被称为系统原型.系统原型的作用是以实物的形式,把系统的框架,组成,式样,界面和交互模式提供给客户.客户根据原型来了解新系统,并对原型做出判断和评价,提出改进的意见.开发人员根据客户意见对原型做进一步的修改、直到客户满意为止.
原型法需要原型生成工具或环境的支持、即高性能的计算机系统,方便的用户界面,模型,方法,式样,数据的存储和管理能力.到了80年代中期,在高性能的计算机、网络,数据库,人工智能,界面技术和第四代语言出现之后,才具备了原型生成工具的技术基础.所以可以说,原型方法是计算机和信息技术发展的产物.
第一个面向对象语言产生于1967年,但是到了80年代后期才引起重视,90年代成为软件开发的主流方法.面向对象中的对象泛指客观世界中的各种事物和主观概念.面向对象法的思想就是在软件开发中直接面向客观领域中的客观事物,运用一整套诸如对象,类,封装、继承,对象连接,对象结构,消息的机制,指导软件开发.由于面向对象法直接面向客观问题,因此较之于其它方法,更接近于问题,简单,易于理解和掌握.
9.3.1 软件的生命周期
9.3.2 软件过程
9.3.3 统一软件开发过程软件的生命周期是从提出软件开发开始,周期性地历经了起始,细化,构造,移交4个开发阶段,形成可运行的软件版本,然后再到达被其它软件所替换的全过程.
在一个软件的完整生命周期中、要循环地历经多次开发阶段.除了第一次之外,每一次循环都是在上一版本的基础上,根据需求和环境的变化,产生一个新的版本.当一个软件被终止,或被其它软件所取代,该软件的生命周期也就宣告结束了.
不同软件的生命周期是不相等的.有些在市场竞争中、被很快淘汰;有些则跟踪用户需求和新技术的发展,不断更新版本,因而具有长久地生命力、生命周期就很长.比如微软的视窗软件,从Windows 1.0开始,不断地更新版本,现在已经发展到Windows XP.
软件过程(software process)是指软件生命周期中一系列相关活动按照确定的次序演绎变化的进程.活动是软件过程的单元、一组相关的活动就构成一个软件过程.比如一个开发过程,包括需求分析,设计,实现,测试等活动.
软件生命周期反映软件实体从生到灭的全过程.软件过程则指在软件生存期中、从不同角度所观测到的软件活动过程.软件生命周期具笼统性,而软件过程具有多面性.
按照国标GB信息技术软件生存期过程)规定,软件过程共包括获取过程,供应过程,管理过程,开发过程,运作过程,维护过程,支持过程和裁剪过程等8个软件过程,如图8.1所示.
9.3.2软件过程
1. 获取过程获取过程(acquisition process)是需方获得一个系统或软件产品的一系列活动.获取过程一般包括开始,范围定义、招标,合同准备,谈判及修改、对供方的监督和验收等项活动.
支持合同获取过程供应过程供需观点需方、供方管理观点管理者管理管理过程维护过程运行过程开发过程
支持过程:文档过程质量保证过程配置管理过程验证过程培训过程评审与审计过程环境建立过程工程观点操作者开发者维护者介入支持过程的人员支持观点图9.2 软件过程
2. 供应过程供应过程(supply process)是供方根据合同、向需方提供软件产品或服务的活动.供应过程包括开始,准备投标,签订协议,编制计划,实施和控制,评审和评价,交付完成等项活动.
3.管理过程管理过程(management process)是各过程中的管理人员对自己过程中的任务和活动所实施的管理活动.管理过程是一个基本过程,适用于必须对过程实施管理的任何一方、比如需方、供方、开发者、操作者、维护者等.管理过程适用于多个过程,比如获取过程,供应过程,开发过程,操作过程,维护过程,支持过程等.管理过程一般包括开始,范围定义、计划,实施和控制,评审和评价,完成等项活动.
4.开发过程开发过程(development process)是开发者根据合同要求,进行系统设计,软件开发或服务的一系列活动.该过程包括建立过程,系统需求分析,系统设计,软件需求分析,软件体系结构设计,软件详细设计,软件编码、软件集成,软件鉴定测试,系统集成,系统鉴定测试,验收,安装和支持等项活动.
5.运行过程运行过程(operation process)是用户和操作人员在用户的业务活动环境中为了使系统或软件产品投入运行所进行的一系列活动.在软件开发过程完成后,通过运行过程能够将系统从开发环境迁移到用户的业务运行环境、在运行过程中对用户的要求提供帮助和咨询,并需要对运行的效果作出评价.运行过程包括过程准备,运作测试,系统迁移,系统运作,对用户运作的支持、系统运行评价,用户运行评价等活动.
6. 维护过程维护过程(maintenance process)是系统或软件产品投入运行之后,为了保证系统或软件产品的性能,适应需求,环境和技术等因素的变化,由维护人员对系统或软件产品所进行修改和改进等活动.维护过程包括问题分析,修改分析,修改和实施,对维护的评审和验收,移植、软件退役等活动.
7. 支持过程支持过程(supporting process)是在软件生命周期中、起着辅助,支持作用的过程.支持过程包括一组过程,主要有文档过程,配置管理过程,质量保证过程,验证过程,评审和审计过程,培训过程,环境建立过程等.
8. 裁剪过程以上列出了7个软件过程.对于具体的系统,软件产品或服务项目,不一定需要以上所有过程及其包含的所有活动.应根据具体要求,配置本项目开发所需要的相关过程.对具体的项目过程和活动配置所涉及的相关活动称为裁剪过程(tailoring process).裁剪过程包括确定项目环境、收集相关信息,选取过程,确定活动和任务,生成裁减结果等活动.
软件生命周期包括多个过程,其中软件开发过程是其重要的内容、每一种开发方法都规定着一种软件开发过程,很不统一.美国Rational公司在研究统一建模语言UML的过程中、通过对各种软件开发过程的比较、于1998年6月公布了统一软件开发过程RUP(Rational Unified Process).从此,结束了软件开发过程的混乱局面,使软件开发过程得到了统一、并简称这种软件开发过程为统一过程.
1.统一过程概述
2.统一过程的特点
3.统一过程的工作流
4.统一过程的工作阶段
5.软件模型统一过程是由时间和工作内容构成的二维结构.从时间维,把软件开发分为初始,细化,构建和移交4个工作阶段.从工作内容维,在软件开发过程中、又存在需求,分析,设计,实现和测试5个核心工作流.统一过程的结构如图9.3所示.
阶段迭代1迭代2图9.3 Rational统一软件开发过程工作流需求分析设计实现测试初始细化构造移交迭代n迭代n-1统一过程具有由用例驱动,以构架为中心、并采用迭代和增量开发模式的三种特点.
(1) 用例驱动用例(use case)描述系统为完成一个功能与用户的一次交互过程.一个用例反映系统的一个功能,系统的所有用例集合反映系统的全部功能,用例集合又被称为用例模型.用例模型既作为需求说明,完整地反映用户需求,又可以驱动软件开发过程.开发人员可以在用例模型的基础上,建立系统的分析模型,设计模型和实现模型.并且以用例模型为基准,建立系统的测试模型.
(2) 以构架为中心软件构架是软件系统的结构,是对软件要素关系的反映.如果把软件构架比作人的骨架,软件的其它内容就相当于血和肉.构架是软件的核心、统一过程把软件构架放到软件开发的中心位置.首先建立结构稳定,具有适应性的软件构架,然后在构架的基础上再填充细节,形成最终的软件系统.
(3) 迭发迭代方式是减小风险,提高效率的有效方法.它把一个大的软件项目通过迭代变为多个袖珍项目,每一个袖珍项目的开发就是一次迭代.在迭发中、可以把具有重大风险的需求实现放到前面,这样随着迭代过程的进展,风险将逐步减小.每一次迭代都会产生一个实现的中间结果,这个结果可以反馈给用户,以征求用户的意见.
这样,在开发过程中、就可以随时更正需求产生的偏差,避免按照瀑布模型直到系统实现阶段,用户才看到实际结果,此时再进行更正将要花费很大的代价.
统一过程中的每一个过程成分被称为一个工作流.工作流是指在软件开发过程中、所需要从事的一个方面的工作.统一过程包括多个工作流、其中核心的工作流有需求,分析,设计,实现和测试.
(1) 需求需求是由用户提出、经开发人员分析所确定的软件系统合理的功能和性能.UML用用例模型来描述软件需求.需求工作流是了解和确定需求的一系列活动.需求工作流的任务是了解业务过程,捕获并分析用户需求,建立反映完整,合理需求的用例模型.
(2) 分析用例模型仅反映软件系统对外所提供的功能.要想实现系统需求,还需要在需求的基础上,把需求转化为软件系统的构成要素.分析工作流的任务是在不考虑系统实现环境和细节的前提下,通过对用例模型的分析,构造出反映用例模型的系统内部要素及其关系的的初步视图,这种视图称为分析模型.
(3) 设计设计工作流需要对分析模型细化,进一步考虑系统的实现环境和非功能性需求,并深入到系统的细节,得出能够指导实施的系统设计模型和实施模型.
(4) 实现实现工作流的任务是实现所设计的软件系统.主要工作有构建系统环境、软件编码、单元测试,系统集成等.
(5) 测试主要包括集成测试,系统测试和验收测试,最后得出可以交付运行的软件系统.需要完成编制测试计划,构造测试用例,实施测试等工作.
(1) 初始阶段初始阶段是软件项目开发的第一个阶段,目的是启动项目.在这个阶段将根据项目开发的提议,确定项目的初步设想,捕获软件的主要功能,分析项目所面临的重大风险,并对项目的可行性进行论证、终止不可行的项目,避免重大风险.一般初始阶段所花费的工作量大约占软件开发总工作量的5-8.
(2) 细化阶段细化阶段主要确定软件的基准构架,即所开发软件系统的核心框架.在这个阶段需要进一步捕获用户需求,一般需要捕获80%左右;再从中选择对系统的功能,结构有重大影响的基准构架的需求,并对这部分需求进行分析,设计,实现和测试.在历经这一全部工作流的过程中、产生基准构架版本,同时形成反映基准构架的系统模型,其中包括用例模型,分析模型,设计模型,实现模型和测试模型.
(3) 构造阶段在软件基准构架的基础上,构建出可以初步运行的软件系统.在构造阶段要对所构建的过程进行详细计划,通过多次迭代,完成构造工作.每一次迭代所得到的结果,将增加到所构建的软件半成品中、最后一次迭代结果就是要交付使用的软件系统.
20~25%8~10%图9.4 软件各阶段的工作比例初始阶段细化阶段构造阶段移交阶段5~8%60~65%(4) 移交阶段移交阶段把构造出的软件系统交付给用户使用.在这一阶段,要对软件进行系统测试,由用户评价,并根据用户提出的修改意见改进.另外,对用户培训、办理移交手续、设置用户使用环境、使软件在用户的环境中正常稳定运行.
四个工作阶段所占的工作比例如图9.4所示软件开发过程中、要建立多种软件模型,每一个工作流都会产生对应的软件模型.软件模型既反映软件在开发过程中、不同时期软件的形态、又反映不同人员对软件的理解和观测角度.一个软件模型就是一个软件的视图.RUP和UML规定在软件开发过程都应该有用例,分析,设计,实施,实现,测试等六个软件模型.这些模型作为一个整体构成软件显现的中间形态、如图9.5所示.
用例模型图9.5 软件模型分析模型设计模型实施模型实现模型测试模型
9.4.1 软件语言和软件建模语言
9.4.2 UML概述
9.4.3 UML的基本内容软件通过语言来描述,描述软件的语言称为软件描述语言或软件语言.软件语言要反映软件的需求,结构,功能,设计,实现,测试和程序等内容.软件语言描述的对象可分为两大部分.一部分描述软件建模过程,包括软件需求,结构,功能,设计,实现和测试等、这部分语言称为软件建摸语言;另一部分描述软件中的程序,称为程序设计语言.
软件是一种智能性产品、软件在开发和形成产品之后,均不具备其它物品的有形特性.但是要使软件开发工程化,就必须在软件开发过程中、把软件的各种中间形态通过一定的方式表现出来,这种对软件中间形态的描述称为软件建模,通过模型来反映和描述软件的中间形态.软件建模语言通常是一套规则的符号集.
不同的软件开发方法规定了不同的软件建摸语言.比如结构化方法采用数据流图来描述软件的需求和功能,用软件结构图描述软件设计方案.在1997年以前、面向对象方法就有50多种、每一种方法的建模语言都不一样.软件建模语言的不统一、给软件开发造成了极大地困难和混乱.针对这一问题,Rational公司组织三个主要面向对象方法的研制专家Grady Booch, James Rumbaugh, Ivar Jacobsn ,对各种建模语言进行分析归纳,在此基础上提出了适应于所有软件开发的统一建模语言UML(Unified Modeling Language),于1997年颁布了第1版,同时被对象管理组织OMG确定为工业标准,现在已经发展到第2版.
作为统一的软件建模语言、UML具有广泛的建模能力.UML是在消化,吸收,提炼现今所有建模语言的基础上提出的,是软件建模语言的集大成者.UML突破了软件的限制,广泛吸收了其它领域的建模方法,把一般事物的建模原理与软件特点结合起来,因而具有坚实的理论基础和广泛的适用性.它不仅用于软件建模,也可用于其它领域的建模.
UML立足于对事物实体,性质,关系,结构,状态及动态变化的全过程进行描述.它可以从不同的角度描述人们所观察到的软件视图,也可以描述在不同开发阶段中的软件形态、还可以建立需求,分析,设计,实现,测试等模型.
作为一种建模语言、UML有严密地语法,语义规范.它建立在元模型理论基础上,包括四层元模型结构,即基元模型,元模型,模型,用户对象.四层结构层层抽象,下一层是上一层的实例.其中所有的概念和要素均有严格的语义定义.
UML采用一组图形符号来描述软件模型,这些图形符号简单,直观,规范、容易学习和掌握;所描述的软件模型,可以直观地阅读和理解,由于具有规范性,所以能够保证模型的准确及一致性.
1.建模要素作为一种建模语言、UML提供了描述事物实体,性质,结构,功能,行为、状态、关系的建模元素,并通过一组图来描述由建模元素所构成的多种模型.UML的建模要素包括基本元素,关系元素和图,如图9.6所示.
UML建模要素基本建模要素关系图结构行为组织注释用例类接口构件协作节点交互图状态图模型子系统框架关联泛化依赖用例图类图对象图顺序图协作图活动图结构图实施图图9.6 UML建模要素(1) 基本建模元素基本建模元素可分为结构,行为、组织,注释四类.结构类用来反映事物和描述性实体,包括用例,类,接口,构件,协作和节点等;行为类反映事物之间的交互过程和状态变化,包括交互图和状态图;组织类用来描述一组模型元素所反映的模型,子系统,框架等组织,包括包、模型, 子系统,框架等;注释类是在建模过程中对模型的注释说明.
(2) 关系元素关系元素反映模型元素之间的关系,包括关联、泛化,依赖,实现等关系.
(3) 图图用来表示软件模型,包括用例图,类图,对象图,顺序图,协作图,状态图,活动图,构件图,实施图等.
2.图形表示UML定义了两类八种图形,如图9.7所示、可用来表示各种模型.
(1) 静态结构图
①类图和对象图:类图用来描述系统的静态结构,由一组类以及它们之间的关系构成.类描述事物以及事物的静态和动态性质,类的关系反映事物之间的关系,主要有关联关系,泛化关系,依赖关系等、UML图动态结构图静态结构图事实图用框图图9.7 UML的类与图例如学校信息系统的一个类图如图9.8所示.图9.8学校信息系统类图系部
名称:Name增加教师减少教师课程
课程编号:Number
课程名称:Name教师
姓名:Name
编号:Number
职称:String学校
校名:Name增加学生删除学生增加部门删除部门学生
学生号:Number
成绩:Number对象图是类图的实例,反映某一时间,在系统中由类图所规定的对象相互之间的关联关系.例如图9.9是作者和图书类图的对象图.
潭浩强:作者姓名=潭浩强性别=男
C语言:图书课程名称=C语言
Basic:图书课程名称= Basic图9.9 对象图作者
性别:String图书
②构件图构件可以是一段源程序代码、一个文本文件,二进制文件或可执行文件.基于构件开发的软件系统,由多个软件构件按照确定的关系构成.构件图用来描述构成软件系统的构件以及它们之间的相互依赖关系,例如图9.10是一个构件图的例子.
课程设置.exe课程.java教师.java班级.java图9.10 构件图
③实施图实施图也称配置图,反映系统的物理节点、及各节点之间的连接结构,如图9.11所示.
校园网事务服务器数据库学生管理课程管理成绩管理图9.11 实施图(2) 动态行为图
①用例图:用例(use case)是用户与软件系统之间,为达到确定目的所进行的一次交互活动.用户向系统提供某些交互要求,系统向用户反馈可见的结果.用例是系统功能需求的反映,用例图用来描述软件系统向一组使用者提供的一组相关的功能.在一个用例图中、有一个或多个使用者与一个或多个用例相互关联.一个系统的全部用例图构成该系统的需求模型.图9.12所示是自动取款机用例图,供读者参考.
取款存款转帐自动取款机图9.12 自动取款机用例图
②交互图:交互图反映事物对象之间消息交互活动,可分为顺序图和协作图两种形式.顺序图反映各对象之间消息传送的顺序,以描述对象之间交互的时间关系.协作图反映为完成一件工作所参与的对象,以及对象之间的消息联系.顺序图和协作图如图9.13和9.14所示.
打印服务器:打印机:打印队列Store(file){打印机忙}Print(file){打印机空闲}:计算机图9.13 顺序图Printf(file)图9.14 协作图
③状态图:状态图描述对象在其生命周期中所具有的各种状态、以及根据事件激励各种状态变化的相互关系.图9.15所示是书店中图书变化的状态图.
图书入库报损图书出库订购销售库存待售报废图9. 15 书店图书状态图
④活动图活动图用来描述事物变化的过程,比如业务流程,工作流程,类中的操作流程等.比如书店图书入库的业务流程活动图如图9.16所示.
图9.16 活动图有误核对入库单图书上架登记库存账库管员填入库单到货通知单领取图书采购员核对图书修改入库单单软件开发主要包括需求,分析,设计,实现和测试五方面的工作.每一种工作有其明确的目标,任务和结果.为了完成确定的工作任务,常把每一种工作分解成为许许多多的活动.这些活动构成完整的工作流、所以常把这五方面的工作称为软件开发的五个核心工作流.
本节将以书店图书销售管理为例,说明软件开发的诸多工作,其中、图书销售管理可分为领书上架,销售图书,结帐,盘架,结算和销售分析等项功能.
9.5.1 需求
9.5.2 分析
9.5.3 设计
9.5.4 实现
9.5.5 测试
1.概述软件开发的目的是把用户的需求转化为软件实体.需求是软件开发工作的基础、只有正确地了解了用户的需求,才能开发出满足用户需要的软件.因此,需求对软件开发至关重要.
捕获用户的合理需求,往往是一件非常困难的工作,因为用户常常只能提出自己的初步设想,而很难提出正确而又具体的需求.有时用户的想法可能不切实际、甚至相互矛盾.另外,用户是一个群体,不同的用户对自己的业务,软件的作用会有不同的理解,提出的要求可能五花八门.这就要求软件开发人员在捕获用户需求时,既要从用户的需要出发,又不能被用户的意见所限制.一定要进行分析,正确取舍、最后得到合理的需求.
9.5.1需求
2.用例模型UML用用例模型(也称为需求模型)来描述用户的需求.它由一组用例图构成,其中包括参与者、用例以及这些模型元素之间的关系等.需求工作就是构建这种能够完整反映用户需求的用例模型.
图9.17表示用例模型的构成,由多张用例图组成.参与者是所有与系统发生交互的外部实体,可以是用户,操作者、也可以是其它系统或者外部硬件.用户不一定全是参与者、有些甚至不与软件系统发生直接的交互关系.参与者也不一定全是用户,如图9.18中的人形图所示.用例用椭圆图表示、如图9.19中的图书销售管理用例.
参与者图书销售管理售书员收款员图9.17 用例模型图9.18 参与者读者图9.19 图书销售管理用例
3.需求的工作需求的工作有、学习所服务领域中的业务知识,捕获,分析,描述用户的需求.
(1) 学习所服务领域中的业务知识软件与所服务的领域有着密切的关系,只有全面掌握其业务知识,才能开发出正确地软件.所以,在开发软件之初、开发者应该首先学习所服务领域中的业务知识.
学习的方法灵活多样,不一定花费专门的时间,正规学习,成为行家.而应该根据专业化的程度,开发人员的专业知识来确定.但是,对于复杂的专业领域,必要时可以建立能够反映所服务领域中的业务活动模型.
(2) 捕获需求捕获需求包括了解和描述两个方面的工作,而这两个方面的工作往往交织在一起,在了解的同时把它描述出来.
首先确定与系统有关的参与者、然后了解每一个参与者与系统之间可能存在的交互关系以及他们的要求和喜好.并在了解的过程中、把它描述出来.在这个过程中、开发人员要从每一个参与者的角度出发,通过调查,了解他们需求.在调查时,还应该尽量扩大调查范围,不要局限于使用本软件的用户和企业领导.
系统需求一般分为功能性需求和非功能性需求.其中功能性需求指软件应该具备的实际功能.比如书店的图书系统,应该提供图书销售管理,订购管理,书库管理等.非功能性需求主要指系统的可操作性,可靠性,安全性,协调性等.
(3) 分析需求用户的水平不同、对所需软件的要求也不同、所以他们提出的需求可能存在差异和矛盾,这就要求开发人员一定要进行认真的分析.比如有些用户对软件的作用报有很高的期望、认为计算机什么都会干,可能提出过高的要求;有些用户可能对计算机了解甚少,把一些容易实现的功能没有提出来.另外,可能有些用户会因为所开发的软件将危及他将来的利益,持抵触心理,甚至提供一些不真实的需求.这就要求开发人员一定要进行深入细致的分析和研究,从而得出合理,可行的用户需求.
分析需求是一项非常细致的工作,它要求分析人员要具备较高的知识素养和软件开发经验.只有这样,才能对用户的需求进行评价和裁决.
(4) 描述需求在UML中、采用用例图来描述需求.在一个用例图中、一般包含一个或多个参与者和用例,用直线表示参与者与用例之间,用例与用例之间的关联关系.用例模型就是反映一个软件系统全部需求的一组用例图.
参与者通过键盘或其它方式向所开发的软件系统提供必要的信息,软件系统再通过屏幕或其它方式向用户展示所处理的结果.这样的过程就是一次交互,用例就是描述这种交互活动的建模元素.
虽然,用例可以通过图形直观地反映用户的需求,但是不能描述参与者与系统的交互过程.因此,可以用文本对每一用例进行说明.图9.20是对图9.19所示用例的说明.
图9.20 图书销售管理用例描述
图书销售管理用例说明:
简况:管理书店的图书销售工作.
图书销售管理活动:
1.售书员根据领书单从书库领书架所需要补充的图书;
2.售书员把领回的图书登记系统并上架;
3.售书员处理读者从书架上选择的图书,打印售书单;
4.收款员收取读者所交的书款;
5.售书员进行日末结帐处理;
6.收款员进行资金结算. 有时一个独立的功能可能涉及到多个参与者和多个用例,因此用例图也可以描述多个参与者和多个用例.参与者与用例之间的交互联系用直线表示、而之间的方框则表示系统的边界、用例之间的依赖关系,用虚线箭头表示.
图9.21所示是图书销售管理展开之后的用例图.图9.21 图书销售管理用例图出纳员售出图书领书上架销售图书销售分析盘架结帐收书款开书单《包含》
通过需求得到系统的用例模型.用例模型能够从外部反映软件系统应该具备的功能,而不能反映其内部结构和构成.要开发一个系统,必须深入到系统内部.另外,用例模型往往采用自然语言来描述,而自然语言缺乏规范性,有时可能存在疏漏或矛盾之处.这就要求开发人员在需求的基础上,再进行分析.
分析工作的目的是得出系统的分析模型.在分析工作中、开发人员需要用一种规范的描述语言来描述分析模型.分析模型将根据用例模型,从抽象的概念层来描述系统的构成和结构.然后,作为设计和实现的依据.分析不同于设计,它是在抽象层考虑系统的结构和构成,而设计则要考虑设计细节,实现环境、效率,速度,可靠性,安全性,并发性,节点分布等内容、所以设计比分析复杂,细致,工作量大.
分析工作主要集中在细化阶段.在初始和构造阶段也要做一些分析工作.初始阶段需要对大约10%的重点用例进行分析,构造阶段再对细化阶段所遗留的用例进行分析.
2.分析模型(1) 分析模型的构成分析模型的构成如图9.22所示、也可以称为分析系统.分析系统作为分析视图用来对系统建模.分析系统由分析包和概念类类构成,分析包由多个概念类和用例分析构成.
图9.22 分析模型分析系统用例分析概念类分析包(2) 概念类概念类是从抽象层所看到的具有确定职责的系统实体.它可以是一个稳定的信息实体,可进行信息的交互处理或者从事控制管理.概念类具有抽象性,是从分析角度所观测到的系统实体,往往对应着设计和实现阶段的多个设计类,有时甚至代表设计中的一个子系统.
幻灯片77概念类的抽象性还表现在采用一种很简捷的方式来表示、仅反映概念类的职责,简要属性和类之间的相互关系.UML把概念类划分为实体类,边界类和控制类,如图9.23所示.
图9.23 概念类的表示
①实体类:用来描述较稳定的客观实体.比如书店管理系统中的图书,订单等.实体类一般对应于业务领域中的客观事物,或者是具有较为稳定信息内容的系统元素.
实体类控制类边界类
形式1:实体边界控制
形式2:
②边界类:是描述系统与参与者之间交互的建模元素.边界类一般保持在较高的抽象层上,它只是对系统与参与者之间交互的抽象建模,并不表示交互的具体内容、以及交互界面的具体形式.例如,售书员界面,出纳员界面等.
应该至少为一个参与者设置一个边界类,用来描述参与者与系统的交互活动.但当一个参与者与系统之间存在较频繁的交互内容、并且各交互较为独立时,可为一个参与者设置多个边界类.
③控制类:是对其它对象实施协调、复杂运算等处理的建模元素.例如在书店管理系统中的开书单等.
(3) 用例分析用例分析包括对一个用例的分析,以及分析的结果.即通过哪些概念类以及概念类之间的交互关系,来实现软件系统对该用例所规定的功能.用例分析通常用两种示图来表示、一种是反映各概念类之间关系和结构的概念类图,另一种是反映各概念类之间动态消息联系的协作图,统称为用例分析结果,简称为用例分析.
对用例模型中每一个用例的分析,都将得出一个用例分析结果,所以用例分析是在分析阶段对用例的进一步深入.用例分析与用例之间存在着一一对应的关系,因此可以从用例分析追踪到用例,如图9.24所示.到设计阶段,要对用例做更深入地刨析,其结果叫用例设计,它可以跟踪到用例分析,也可以跟踪到用例本身.
《跟踪》
用例分析结果图9.24 用例分析到用例的跟踪
①概念类图:用来抽象地描述用例概念类之间的关系所呈现的静态结构.概念类图抽象度较高,从宏观角度描述各概念类之间关系,一般不涉及过多的细节.销售图书用例的概念类图如图9.25所示.
图9.25 销售图书概念类图核对书单出纳员界面售书员界面书单书目出售图书书款帐在架图书返回80
②交互图:反映用例功能实现过程中参与者向系统发送消息,系统中各概念类的对象之间为完成用例功能而进行的消息交互,以及软件系统向参与者返回消息的过程.通过交互图可反映各个消息之间的联系.销售图书的用例协作图如图9.26所示.
图9.26 销售图书协作图
10:销售图书:开书单:售书员界面
3:取图书信息
11:核对书款
5:收书款
13:售出图书
12:在架取图书
9:存书款数据
8:收书款
7:书单信息
6:核对书单
4:送书单信息
2:开书单
1:销售图书:售书员:出纳员:出纳员界面:核书单:书单:书目:收书款:书款帐(4) 分析包分析包是对分析系统的分解,它按照内容的相关性,把多个聚合度较强的概念类和用例分析划归为一个分析包.一个分析包除了概念类和用例分析之外,也可包含其它分析包.其内部具有较强的聚合性,而相互之间的耦合性应尽量低.分析包一般根据某一主题得出、并作为设计模型中的子系统.从图9.22可以看出、由多个分析包构成一个分析系统.
3.分析的工作分析是根据用例模型,通过分析得到系统的分析模型.分析包括四方面的工作:构架分析,分析用例,概念类分析,分析包.
(1) 构架分析构架分析是确定系统的基本构架.它是在用例模型的基础上,根据对需求和业务相关性的分析,确定出构成分析模型的各个分析包、各分析包之间的关系,以及在业务活动中处于重要地位的概念类.
这些、确定了系统的基本构架.例如对图书销售管理用例模型的分析,可以确定如图9.27所示的分析包和概念类.
这些分析包以及包之间的关系如图9.28所示.图9.28图书销售管理包结构领书上架图书销售管理系统图9.27图书销售管理分析包和分析类架存图书书款账(2) 分析用例分析用例将对用例模型中的每一个用例逐一进行分析,并得出用例分析结果.分析用例应根据用例所要实现的功能,以及参与者与用例之间的交互内容、确定该用例所涉及到的概念类,以及各类之间的关系,并用概念类图描述出来.然后,再用协作图描述概念类的对象之间所要传送的消息.
①确定概念类:首先确定分析用例将要涉及到的所有概念类.概念类分为实体,边界、控制三种类型.确定用例的概念类,需要考虑用例所要完成的功能,所涉及到的业务实体,用例与参与者交互的内容以及用例所实现的控制过程;并为参与者设置对应的边界概念类.对一个用例来讲,一般为一个参与者设置一个边界类就够了,但是交互的内容确实需要多个边界类时,可根据需要设置,不过这种情况较少;然后,确定用例需要存储和处理的稳定信息体以及在系统中反映的业务实体,一个实体设置一个概念类;最后,确定对实体类进行控制的控制类.
确定三种概念类之后,还要确定各个概念类之间的关系.一般类之间存在泛化,关联、聚合和组成等关系.一般用概念类图描述分概念之间的关系.图9.25所示是根据书店管理中的销售图书用例的分析,确定出来的概念类,以及由概念类构成的概念类图.因为有售书员和出纳员两个参与者与该用例进行交互,所以需要设置售书员界面和出纳员界面两个边界类.该用例涉及到的业务实体以及要处理的稳定信息体有书目,书单,在架图书,售出图书,书款帐等.因此,设置了对应的五个实体类.
另外,根据处理的需要、设计了开书单,核对书单,收书款,出售图书四个控制类.通过关联关系把这些概念类联系起来,构成图9.25所示的销售图书用例的概念类图.
②用协作图描述分析对象之间的交互关系:在确定了概念类,以及概念类之间的关系之后,下来就需要用协作图来描述各分析对象之间的交互过程.交互过程反映参与者与用例,以及用例之中的概念类之间的信息交互活动.因此可以从参与者给边界类发送消息开始,追踪边界类在给哪些分析发送消息,一直到用例给参与者返回处理结果为止.图9.26所示是销售图书用例的协作图.
(3) 概念类分析以上确定了各个用例的概念类,下面对每一个概念类进行更深入的分析,以确定概念类的职责,属性和与其它概念类之间的关系.概念类的职责可以用比较简练的自然语言来叙述;概念类的属性需列出反映类特性的主要属性.例如,书目概念类的职责是图书名录信息,其属性有书号,书名、作者、出版社,出版日期,单价等.
概念类之间的关系有关联、泛化和依赖.聚合与组成是关联的两种特例.
在构架分析时已经确定了分析包.在对概念类和用例进行分析之后,再对分析包进行分析,以调整各个分析包中的内容、使分析包之间的耦合关系尽量地少,尽可能地增大分析包内部的聚合性.最后,确定各分析包之间的依赖关系.
在软件开发中、设计工作的目的是构建软件系统的设计模型.设计属于软件开发的第三项工作,其目的是构建软件系统的设计模型.分析模型是软件系统的逻辑模型,它回避了实现环境和细节,提供了一个高抽象度的系统视图.设计模型将要在分析模型的基础上,深入到实现细节,并考虑软件系统的环境、编程语言、数据库技术,用户界面技术,事务管理技术,并发分布技术等因素,形成指导软件实现的系统模型.设计工作包括构架设计,设计类设计,用例设计和设计子系统.
2.设计模型(1) 设计模型的构成设计模型的构成如图9.29所示、也称为设计系统,作为设计视图来对系统建模.设计系统由设计子系统,设计类,用例设计和接口构成.设计子系统处于中间层,是设计的一种抽象机制.
图9.29 设计模型设计类用例设计设计系统设计子系统(2) 设计类设计类是对概念类的细化,是对所实现的系统中类的抽象.设计类的设计需要描述设计类的属性,操作,方法,关系等、还要反映其可见性,导航,操作的参数,主动性等特性.
(3) 用例设计用例设计是对用例分析的设计,包括用例的设计类图,交互图和设计事件流描述等三部分.根据用例设计可以追踪到一个用例分析,根据用例分析可以追踪到一个具体的用例,其示意如图9.30所示.
图9.30 用例设计到用例分析和用例的跟踪
①设计类图:用来描述一个用例的设计类,以及各个设计类之间的关系所呈现的静态结构.与概念类图相比较、设计类图更详细,更具体.它所反映设计类之间的关系必须得到程序设计语言的支持、例如所采用的语言如果不支持多重继承,在设计类图中就应把多重泛化转化单继承.另外,在设计类图中还应该表示出类之间关联的导航关系.设计类图可以追踪到概念类图,以及对应的用例.
②交互图:描述在实现一个用例的过程中、各个设计类之间的消息联系过程.一般先从参与者向系统发送消息,启动一个用例;边界类接收参与者发来的消息,并向其它对象发送消息,启动其它对象执执行相应的操作.经过各个对象之间消息的传递和对象操作的执行、从而实现了用例的功能;最后,返回给参与者所要的执行结果.
因为交互图要表现对象之间消息的传送顺序,所以交互图一般采用顺序图.
③设计事件流描述:复杂用例的消息关系可能很复杂,单靠设计类图和交互图有时难以表达清楚,因此可用设计事件流描述来对交互图作进一步的说明.
(4) 接口接口是设计类或设计子系统对外所能提供的操作.它不涉及对设计类或设计子系统操作的实现,只描述设计类或子系统能够对外提供的操作;它也是设计类或设计子系统对外提供的操作视图,其它设计类或子系统通过接口来与提供接口的设计类发生关系.其示意如图9.31所示.
接口把设计类与外部隔离开来.只要接口不变,设计类的改变不会影响到其它设计类与本设计类之间的关系.接口提高了系统的独立性和适应性.
图9.31 接口的实现一个对外提供接口的设计类,必须提供实现这个接口的操作的方法.一个设计类可以向不同的对象提供不同的操作接口.一个对外提供接口的子系统必须包含提供接口的设计类和其它子系统.一个承接接口的设计类,需要提供实现这个接口操作的方法.
3.设计的工作(1) 构架设计构架设计也称为结构设计,其目的是确定系统的总体构架.
①分布结构设计:分布结构设计主要是确定系统的节点分布和节点之间的网络结构和网络配置.节点是系统中能够独立工作的处理单元.一个客户机、业务处理服务器,数据库服务器均是节点、节点之间通过网络连接.分布结构一般有两层结构,三层结构和多层结构.两层结构也就是CS结构,三层结构是客户层,应用处理层和数据处理层.小型系统多采用两层结构,中大型系统一般采用三层结构.
分布结构设计需要确定系统由哪些节点构成,各个节点的处理能力、存储能力、节点连接所采用的网络协议以及网络的总体结构;另外还要考虑对系统可靠性,安全性,冗错能力的要求等.
例如,如图9.32所示的图书管理系统,共设置有4个节点、采用CS结构,节点之间用局域网连接,通信协议采用TCPIP.
图9.32 图书管理系统分布结构TCPIP图书采购收款图书查阅
②软件结构设计:是把软件分解成为设计子系统,并确定由设计子系统及其接口构成的软件结构.软件结构一般分为图9.33所示的四层结构模式.其中应用层是用户应用软件所在的层次,又分为专用应用层和通用应用层.其中通用应用层中的子系统可以被多个专用应用子系统引用.中间件层放置支撑系统运行的有关中间件,比如通信工具,数据库引擎,分布对象机制等.系统软件层则放置操作系统,低层协议等系统软件.
图9.33 软件系统的四层结构模式中间件层专用应用层书单管理书目管理通用应用层架存图书管理售出图书管理书款管理系统软件层虚拟机Java.swing tJava.rmi tWindowsWeb浏览器软件结构设计的第一项工作是设计应用子系统,其中包括专用应用层和通用应用层的子系统.在这两层包括了应用软件的结构,设计时首先从分析包结构出发,识别设计子系统,对每一个分析包进行分析.开始时,可以简单的为每一个分析包确定对应的设计子系统.
然后,再对每一个设计子系统进行分析,以确定是否还需要再进一步的分解.对于复杂分析包所映射的设计子系统,可以分解为多个设计子系统.
软件结构设计的第二项工作是确定中间件.中间件层与系统环境、应用要求有关.例如,如果系统采用浏览器模式,就需要选择Web浏览器作为中间件;如果具有分布处理要求,就需要选择DCOM,CORBA或java.rmi等具有分布对象处理能力的中间件.另外,还需要根据数据处理的要求,选择合适的数据库系统.
软件结构设计的第三项工作是确定系统软件层所采用的软件系统,一般包括操作系统,网络协议等.例如操作系统采用Windows NT,网络协议采用TCPIP等.
除了以上三项工作之外,软件结构设计还需要考虑各个设计子系统之间的接口和依赖关系,子系统在各节点上的分布设计等方面的工作.
现在进一步讨论书店图书管理系统中图书销售部分的软件结构设计.在专用层是图书销售设计子系统,下来又分出开书单,出售图书,收书款三个设计子系统.在通用应用层设置了书单管理,书目管理,架存图书管理,售出图书管理和书款管理五个设计子系统,这五个子系统可被上层专用子系统引用.在中间件层,java.swing用于界面设计,java.rmi进行远程对象通信,java虚拟机提供给客户机与服务器搭建java平台.在系统软件层采用windows操作系统,网络协议采用TCPIP.
(2) 用例设计用例设计是对一个用例所进行的设计工作,并要得到设计结果.用例设计可以跟踪一个用例分析,在用例分析的基础上进行设计,设计结果包括用例设计类图和交互图.
①用例设计类图:用来描述实现一个用例的设计类所构成的静态结构.用例设计类图是对用例概念类图的进一步深化.首先需要确定实现该用例应该具有的设计类,再确定各个设计类之间的关系.
在用例设计类图中、对每一个类可以用简单的方框类符号来表示、而不需要详细列出每一个设计类的属性,操作.设计类的内容将在下面介绍.图9.34所示是销售图书中开书单用例的设计类图,供读者参考.
打印进程图9.34 开书单的设计类图
②用例设计交互图:表示各设计类中对象之间的消息交互过程,为了反映各个对象之间的消息交互关系,一般用顺序图表示.图9.35所示是开书单的顺序图.
图9.35 开书单的顺序图存书单打印书单取图书信息输入书号:打印进程(3) 设计类的设计用例设计之后,需要对所有设计类进行详细设计,其中包括确定类的属性,操作,关系以及类的状态等.
属性:标出每一个属性的名称,类型,可见性以及属性的约束和取值范围.另外,最好用所采用的编程语言的语法规则来描述属性.
操作:识别类的所有操作,确定每一个操作的名称,参数,可见性和约束等.
关系:确定类与类之间的关系,主要有关联关系,泛化关系,依赖关系和实现关系.关联关系又包括聚合和组合关系.还应该确定关联的多重性,角色名称,关联类,导航等.对于泛化关系需要确定所采用的编程语言是否支持多重泛化.如果不支持多重泛化,就需要通过接口或其它技术把多重泛化转变成为单泛化.如果通过接口描述设计类,接口和设计类之间是实现关系,需要标出这种实现关系.
图9.36 订单设计类
订单编号: Number
供书商编号: Number
订书日期: Date
书号: Number
数量: Number
计划到货日期:Date
实际到货日期: Date增加订单项(订单项)删除订单项(订单编号,书号)填到货日期(订单编号,书号,日期)
图书编号:Number
图书名称:String供书商
供书商编号:Number
供书商名称:String订单
状态:如果类的对象处在多种状态、可以通过状态图描述对象所处的状态、以及各个状态之间的转换关系.
图9.36 表示订单设计类.该类与图书类和供书商类存在关联关系,通过书号和供书商编号两个属性与图书和供书商两个类进行关联导航.
设计阶段所得到的设计模型只是软件系统的详细蓝图,它并不等于实际的软件系统.实现的任务就是把设计模型通过一系列迭代过程,转变成可以运行的软件系统.软件系统由源程序可执行代码以及相关的数据结构构成,这些内容被组织成多个软件构件.实现工作的主要任务是编制,调试程序代码.但是同时还需要确定程序代码的组成构件,构件之间的关系以及所有构件在节点中的分布.也就是用实现模型来描述所要实现的软件系统.
实现需要通过多次迭代才能完成.每一次迭代将在上一次迭代的基础上,实现一个子系统或子系统的部分任务,并把本次迭代所实现的结果加入到已实现的系统中、通过多次迭代就可以产生所要的软件系统.
2.实现模型实现模型用来描述所实现的软件系统的组成结构.实现模型由多个实现子系统构成,每一个子系统又包括若干个软件构件和构件的接口,如图9.37

ppt文档的标签：软件工程

更多推荐标签：养猪贷款唐诗杂论缺貨通知單科举百年培训总监职责办公中级报关专业论文专业烟店监管宜昌陈艾娃发电机房报告思想动态报告表演心得函数的使用经济增长理论媒体推广计划预防亚健康共青团会设备日常维护论证券市场上司公司治理机制预算补助冰箱购销合同对党的总结梁淑荣文化古蹟旅游特殊工种学习杭州两日游家乡陕西调查