实用软件工程课件第8章
软件工程导论PPT课件-第8章-维护
分析评价,修改设计,编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序,缺乏必要的文档说 明,难于确定数据结构、系统接口等特性的情况下,进行 的软件维高昂
明显代价:高昂的维护费用,已上升达80%左右; 无形代价:
的工作环境,或适应已变动的数据或文件; (4)为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错,以及验证、修改的回归测试过程, 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求, 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化, 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等,或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审
(软件工程理论、方法与实践)第8章分布式系统体系结构
基于服务的架构设计方法
总结词
基于服务的架构设计方法是一种以服务为中心的设计方法,通过将系统功能封装为可复用的服务,实 现松耦合的分布式系统。
详细描述
01
02
分布式性
组件分布在不同的物理节点上,可以 位于不同的地理位置。
03
通信能力
组件之间通过通信进行协调和交互。
可靠性
分布式系统具有容错性和可恢复性, 能够保证系统的可靠运行。
05
04
并发性
多个组件可以并行执行,提高系统的 整体性能。
分布式系统的应用场景
云计算平台
如亚马逊AWS、谷歌云等,提供计算、存储、网络等 服务。
总结词
基于代理的分布式系统通过使用智能 代理来处理分布式任务,具有自治性、 智能性和协作性等特点。
详细描述
基于代理的分布式系统案例包括:1. 分布式 计算市场案例,如网格计算和云计算平台, 通过智能代理实现资源的共享和交易;2. 智 能家居案例,通过智能代理实现家庭设备的 互联和控制,提高生活便利性。
运维
分布式系统的运维需要关注系统的运行状态 和性能,以及服务的可用性和可靠性。这需
要使用一些监控工具和技术,如 Prometheus、Grafana等,以便及时发现 和处理系统中的问题。同时,还需要建立完 善的运维流程和规范,以确保系统的高可用
性和高可靠性。
05
分布式系统案例分析
基于代理的分布式系统案例
测试方法
对于分布式系统的测试,需要采用一些特定 的方法,如模拟测试、灰度测试、故障注入 测试等。这些方法可以帮助开发人员模拟各 种实际运行场景,以便更好地发现和修复系 统中的问题。
软件工程 第八章 面向对象的设计方法
第八章面向对象的设计方法本章采用基于UML的面向对象设计方法的将分析模型转换为设计模型。
如第五章所述,面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成;设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。
为完成这一转换过程,设计人员必须处理以下任务:(1)针对分析模型中的用例,设计实现方案。
实现方案用UML交互图表示。
(2)设计技术支撑设施。
在大型软件项目中,往往需要一些技术支撑设施来帮助业务需求层面的类或子系统完成其功能。
这些设施本身并非业务需求的一部分,但却为多种业务需求的实现提供公共服务。
例如,数据的持久存储服务、安全控制服务和远程访问服务等。
在面向对象设计中,需要研究这些技术支撑设施的实现方式以及它们与业务需求层面的类及子系统之间的关系。
(3)设计用户界面。
(4)针对分析模型中的领域概念模型以及第(2)、(3)两个步骤引进的新类,完整、精确地确定每个类的属性和操作,并完整地标示类之间的关系。
此外,为了实现软件重用和强内聚、松耦合等软件设计原则,还可以对前面形成的类图进行各种微调,最终形成足以构成面向对象程序设计的基础和依据的详尽类图。
面向对象的软件设计过程如图8-1-1所示。
图8-1-1 面向对象的软件设计过程第一节设计用例实现方案UML 的交互图(顺序图、协作图)适于用例实现方案的表示。
因此,本节首先介绍交互图的语言机制,然后探讨用例实现方案的设计方法。
该设计方法包含如下3个步骤:(1)提取边界类、实体类和控制类;(2)构造交互图;(3)根据交互图精华类图。
一、顺序图顺序图用来描述对象之间动态的交互关系,着重表现对象间消息传递的时间顺序。
在顺序图中,参与交互的对象位于顶端的水平轴上,垂直轴表示时间,时间推移的方向是自上而下的。
顺序图中的对象一般以“对象名:类名”的方式标识,但也可以仅采用缩写形式“对象名”或者“:类名”。
软件工程课件之第8章维护第6版张海潘编著
用户文档
用户文档至少应该包括下述5方面的内容:
功能描述,说明系统能做什么; 安装文档,说明怎样安装这个系统以及怎样使系统
软件维护过程
维护报告
维护要求表或称软件问题报告表,由申请维 护的用户填写。
软件修改报告,由软件组织内部制定,指明:
满足某个维护要求表中提出的要求所需要的工 作量;
维护要求的性质; 这项要求的优先级; 与修改有关的事后数据;
维护的事件流
维护的事件流
尽管维护申请的类型不同,但都要进行同样 的技术工作:
系统文档
所谓系统文档指从问题定义、需求说明到验收 测试计划这样一系列和系统实现有关的文档。
描述系统设计、实现和测试的文档对于理解程 序和维护程序极端重要
从概貌到每个方面每个特点,从抽象到具体, 有逻辑地介绍系统
可维护性复审
在需求分析阶段的复审过程中,应该对将来要 改进的部分和可能会修改的部分加以注意并指 明;应该讨论软件的可移植性问题,并且考虑 可能影响软件维护的系统界面。
维护的问题
与软件维护有关的绝大多数问题,都可归 因于软件定义和软件开发的方法有缺点:
① 理解别人写的程序通常非常困难,而且困难程 度随着软件配置成分的减少而迅速增加。
② 需要维护的软件往往没有合格的文档,或者文 档资料显著不足。
③ 当要求对软件进行维护时,不能指望由开发人 员给我们仔细说明软件。
的。
软件维护工作量
各类维护工作量 所占比例
维护工作量在软件生 命周期所占比例
软件工程导论课件第8章
5. 数据重构 对数据体系结构差的程序很难进行适应性和 完善性维护,因此,数据体系结构比源代码对程序 的长期生存力有更大影响。 数据重构是一种全范围的再工程活动。由于 数据重构对程序体系结构及程序中的算法有很大影 响,对数据的修改必然会导致程序体系结构或代码 层的改变。
3
2.适应性维护 为适应变化了的环境界面而修改软件的活动, 称为适应性维护。包括: (1)因硬件或支撑软件改变引起的变化; (2)将软件移植到新的机种上运行; (3)因数据环境的变化而做的变更。 这类维护大约占软件维护总工作量的25%。
4
3.完善性维护 为了满足用户要求,就得对软件进行修改和 扩充,我们称这种维护为完善性维护。完善性维护 主要包括: (1)提高处理效率; (2)提高性能。 在整个维护工作中, 完善性维护大约占50% 左右,区居第一位。
3. 逆向工程 软件的逆向工程是,分析程序以便在比源代码 更高的抽象层次上创建出程序的某种描述的过程, 也就是说,逆向工程是一个恢复设计结果的过程。 4. 代码重构 某些老程序的体系结构比较合理,但是,一些 模块的编码方式却是难于理解、测试和维护的。在 这种情况下,可以重构这些模块的代码。 通常,代码重构并不修改程序的体系结构,它 只关注个体模块的设计细节以及在模块中定义的局 部数据结构。如果重构扩展到模块边界以外并涉及 软件体系结构,则重构变成了正向工程。
13
(四)软件维护过程 维护过程的实质是对软件定义和开发过程的修 改和压缩。维护过程的主要任务是:建立维护机构, 填写维护报告和评价,为每个维护要求规定一种规 范化的处理序列,建立对维护活动的登记制度及规 定评价复审的标准。 1.维护组织 机构中有一名维护管理员总负责,每项维护要 求都通过维护管理员转交给相应的系统管理员去评 价。系统管理员对维护任务做出评价之后,由变化 授权人决定应该进行的活动,最后由系统管理员去 执行维护任务。
软件工程第八章维护
软件工程第八章维护第一点:软件维护的定义和重要性软件维护是指在软件发布后对其进行的一系列操作和活动,旨在确保软件系统的持续可用性、可靠性和性能。
软件维护是软件开发生命周期中的一个重要环节,它涉及到对软件进行修正、优化和升级。
软件维护的重要性体现在以下几个方面:1.保障软件质量:软件在实际运行过程中可能会出现各种问题,维护可以帮助及时修复这些问题,保证软件的正常运行。
2.提高用户满意度:通过维护,可以对软件进行功能优化和界面调整,使其更加符合用户的需求,提高用户的使用体验。
3.降低风险:软件维护可以帮助提前发现并解决潜在的风险,避免因软件问题导致的损失。
4.延长软件寿命:通过不断的维护和升级,可以使软件适应不断变化的环境和需求,延长其使用寿命。
5.提高开发效率:良好的维护可以避免因软件问题导致的重复开发,提高开发团队的效率。
第二点:软件维护的类型和策略软件维护可以分为以下几种类型:1.改正性维护:这种维护类型主要是针对软件中存在的问题和错误进行修复,保证软件的正常运行。
2.适应性维护:随着环境的变化和用户需求的变化,软件需要进行相应的调整和优化,以适应新的环境和工作需求。
3.完善性维护:这种维护类型主要是针对软件的功能进行增强和扩展,以满足用户的新需求。
4.预防性维护:预防性维护是为了避免软件出现潜在的问题和风险,提前对软件进行调整和优化。
在进行软件维护时,可以采取以下策略:1.计划维护:制定详细的维护计划,包括维护的时间、内容、责任人等,确保维护工作的有序进行。
2.变更管理:对于软件的修改和更新,需要进行严格的变更管理,确保每次变更都是经过审核和评估的。
3.版本控制:通过版本控制工具,对软件的不同版本进行管理,确保软件的每个版本都是可追踪和可恢复的。
4.文档管理:对软件的维护过程和结果进行详细的文档记录,方便对软件进行管理和维护。
5.持续集成:将软件的维护工作与开发工作结合起来,通过持续集成的方式,确保软件的质量和稳定性。
《软件工程》第八章 软件维护与再工程
软件可维护性-主要影响因素
可移植性:指程序转移到一个新的计算环境的难易 程度。
影响软件可移植性的因素有:信息隐蔽原则;模块 独立;模块化;高内聚低耦合;良好的程序结构; 不用标准文本以外的语句等
一个可移植的程序应具有结构良好、灵活、不依赖 于某பைடு நூலகம்具体计算机或操作系统的性能
软件可维护性-主要影响因素
软件维护的概念-维护成本
其它一些因素:如应用的类型、数学模型、 任务的难度、IF嵌套深度、索引或下标数等, 对维护工作量也有影响
软件维护的过程-维护组织
维护组织结构图
软件维护的过程-维护组织
系统监督员一般都是对程序(某一部分)特别熟 悉的技术人员。 在维护人员对程序进行修改的过程中,由配 置管理员严格把关,控制修改的范围,对软 件配置进行审计 。 维护管理员、系统监督员、修改控制决策机 构等,均代表维护工作的某个职责范围 。
如果已经开始保存维护记录,可以对维护工作做 一些定量度量,至少可以从如下7方面进行评价:
每次程序运行平均失败的次数; 用于每一类维护活动的总人时数; 平均每个程序、每种语言、每种维护类型所必需的程序 变动数; 维护过程中增加或删除源语句平均花费的人时数; 维护每种语言平均花费的人时数; 一张维护请求表的平均周转时间; 不同维护类型所占的比例;
软件维护的过程-维护记录
软件修改报告指明:为满足维护申请报告提 出的需求所需的工作量、本次维护活动的类 别、本次维护请求的优先级、本次修改的背 景数据。在拟定进一步维护计划前,软件修 改报告要提交给修改决策机构,供进一步规 划维护活动使用 保存维护记录的第一个问题就是哪些数据值 得保存?
软件维护的过程-维护评价
软件维护的概念-维护问题
计算机导论-第8章 软件工程
10
8.1.2 软件生命周期
5.软件测试
在软件分析、设计和程序编写过程中,难免有各种各样的错误,需要通过测试来查找 和修改,以保证软件的质量。其主要工作如下。
(1)单元测试 查找各模块在功能和结构上存在的问题并加以纠正。 (2)集成测试 将已测试通过的模块按照一定顺序组装起来进行测试。 (3)有效性测试 按照规定的各项需求,逐项进行测试,判断已开发的软件是否合格,能否交付用户使 用。
21
8.1.3 软件开发模型
4.螺旋模型
螺旋模型的思想是:使用原型 及其他方法来尽可能地降低风险。 它在软件开发的每个阶段,都增加 了一个风险分析过程。螺旋模型结 合了快速原型模型的迭代性质和瀑 布模型的系统性和可控性特点,适 用于大型软件的开发。螺旋模型由 4部分组成:制定计划、风险分析、 实施开发、客户评估,如图8-5所 示。在笛卡尔坐标的4个象限上分 别表达了4个方面的活动。
特别地,从经济学的意义上来说,考虑到软件庞大的维护费用远比软件开发费用要 高,因而开发软件不能只考虑开发期间的费用,而应考虑软件生命周期内的全部费用。 因此,软件生命周期的概念就变得特别重要。
6
8.1.2 软件生命周期
同任何事物一样,软件也有一个孕育、诞生、成长、成熟、衰亡的生存过程。软件生 命周期是指一个计算机软件从功能确定、设计,到开发成功投入使用,并在使用中不断地 修改、增补和完善,直到停止使用该软件的全过程。
软件工程第8章软件维护
8.1 软件维护的种类
1. 校正性维护(Corrective maintenance) 为了识别和纠正软件错误、改正软件性能上的缺陷、排
除实施中的误使用,应当进行的诊断和改正错误的过 程,就叫做校正性维护。
8.1 软件维护的种类
2. 适应性维护(Adaptive maintenance)
随着计算机的飞速发展,外部环境(新的硬、软件配置)或数据环 境(数据库、数据格式、数据输入/输出方式、数据存储介质)可 能发生变化,为了使软件适应这种变化,而去修改软件的过程就 叫做适应性维护。
8.4.1 影响可维护性的因素
除了与开发方法有关的因素之外,以下因素会对可维 护性有重要影响:
(1)软件设计人员是否受到严格的规范化工作培训; (2)是否采用主流的编程语言; (3)是否采用主流的操作系统; (4)是否采用标准化的文档资料结构和文档形成机制; (5)是否保存规范化的测试资料。
8.4.2 软件可维护性的度量
8.3 软件维护的实施
为了有效地进行软件维护,应事先就开始做组织工作。 首先需要建立维护的机构,申明提出维护申请报告的 过程及评价的过程;为每一个维护申请规定标准的处 理步骤;还必须建立维护活动的登记制度以及规定评 价和评审的标准。
8.3.2 软件维护申请报告
软件维护申请应按规定的方式提出。软件维护组织通 常提供维护申请报告(MRR, Maintenance Request Report),或称软件问题报告,由申请维护的用户填写。
8.1 软件维护的种类
完善性维护 50%
预防性维护5%
改正性维护 20%
适应性维护 25%
图11.1 各类维护的比重
8.2 软件维护的特点
8.2.1 软件维护面临的困难 统计资料表明,有代表性的软件开发组织用于校正性
软件工程课件-第八章维护ppt
2. 适应性维护
计算机科学技术领域的各个方面都在迅速进步,大约每 过38个月就有新一代的硬件宣告出现;另一方面,应用软 件的使用寿命却很容易超过十年,远远长于最初开发这个 软件时的运行环境的寿命。因此,适应性维护就是为了和 变化了的环境适当地配合而进行的修改软件的活动,是既 必要又经常的维护活动。
4. 预防性维护
当为了提高未来的可维护性或可靠性,或为了给未来的 改进工作奠定更好的基础而修改软件时,就出现了第四类维 护活动,这类维护活动称为预防性维护。通常,把预防性维 护定义为:“把今天的方法学应用于昨天的系统以满足明天 的需要”。也就是说,预防性维护就是采用先进的软件工程 方法对需要维护的软件或软件中的某一部分,主动地进行重 新设计、编码和测试。
8.3.1 维护组织 虽然通常并不需要建立正式的维护组织,但是,即使对
于一个小的软件开发团体而言,非正式地委托责任也是绝 对必要的。维护机构成员一般包括:配置管理员、维护控 制员、系统管理员、一般维护工作人员。
每个维护要求都通过维护管理员转交给相应的系统管理 员去评价,见下页图示。
维护机构
维护要求 (软件问题报告)
● 当必须把软件工程师调去从事维护工作时,将在开发 过程中造成混乱。
8.1.2.3 维护的问题很多
与软件维护有关的绝大多数问题,都可归因于软件定 义和软件开发的方法有缺点。在软件生命周期的头两个时 期没有严格而又科学的管理和规划,几乎必然会导致在最 后阶段出现问题。下面列出和软件维护有关的部分问题:
8.1.2.2 维护的代价高昂 8.1.2.3 维护的问题很多
8.1.2.1 结构化维护与非结构化维护差别悬殊
实用软件工程( 第2版)7、8章
完整、正确的脚本为建立动态模型奠定了必要的基础。但是,用自 然语言书写的脚本往往不够简明,而且有时在阅读时会有二义性。为了 有助于建立动态模型,通常在画状态图之前先画出事件跟踪图。UML顺 序图(也称为事件跟踪图)中, 一条竖线代表应用领域中的一个类,每 个事件用一条水平的箭头线表示,箭头方向从事件的发送对象指向接受 对象,时间从上向下递增。
7.1 面向对象分析方法
明确了对象、类和类之间的层次关系之后,需要进一步 识别出对象之间的动态交互行为,即系统响应外部事件或操 作的工作过程。一般采用顺序图将用例和分析的对象联系在 一起,描述用例的行为是如何在对象之间分布的。也可以采 用协作图、状态图或活动图。
最后,需要将需求分析的结果用多种模型图表示出来, 并对其进行评审。由于分析的过程是一个循序渐进的过程, 合理的分析模型需要多次迭代才能得到。
7.1 面向对象分析方法
边界类示意图 控制类示意图 实体类示意图
目标系统的类可以划分为边界类、控制类和实体类。
➢ 边界类代表了系统及其操参与者的边界,描述参与者与 系统之间的交互。它更加关注系统的职责,而不是实现 职责的具体细节。通常,界面控制类、系统和设备接口 类都属于边界类。
➢ 控制类代表了系统的逻辑控制,描述一个用例所具有的 事件流的控制行为,实现对用例行为的封装。通常,可 以为每个用例定义一个控制类。
主机联接有问题,则执行异常事件流e。
a1. 提示用户输入无效密码,请求再次输入;
(5)ATM提供以下选项:存钱、取钱、查询。
a2.如果三次输入无效密码,系统自动关闭,退出客户银行卡。
(6)用户选择取钱选项。
(7)ATM提示输入所取金额。
子事件流b:
软件工程导论第八章-软件质量与质量保证
8.7 结构化程序的测试 8.7.5 软件测试技术
1. 静态分析技术 (3)符号执行是一种符号化定义数据,并
为程序每条路径给出符号表达式,对 特定路径输入符号,经处理输出符号, 从而判断程序行为是否错误,达到分 析错误的目的。
8.7 结构化程序的测试
8.7.1 软件测试的目的 8.7.2 软件测试的原则 8.7.3 软件测试的对象 8.7.4 软件测试的基本过程
8.7 结构化程序的测试 8.7.1 软件测试的目的
1. 软件测试的目的 (1)软件测试是确认软件的质量,其
一方面是确认软件做了所期望的事 情,另一方面是确认软件以正确的 方式来做了这个事件。 (2)软件测试是提供信息,比如提供 给开发人员或项目经理的反馈信息, 为风险评估所准备的信息。
8.6 软件质量保证的标准
2.ISO 9001标准 (8)产品标识和可跟踪性 (9)过程控制 (10)审查和测试 (11)审查、度量和测试设备的控制 (12)审查和测试状态 (13)对不符合标准产品的控制 (14)改正和预防行动
8.6 软件质量保证的标准
2.ISO 9001标准 (15)处理、存储、包装、保存和交付 (16)质量记录的控制 (17)内部质量审计 (18)培训 (19)服务 (20)统计技术
测试过程中产生的基本文档如下: (1)测试计划: 通常包括单元测试和集成测试,
确定测试范围、方法和需要的资源等。 (2)测试过程: 详细描述和每个测试方案有关
的测试步骤和数据,包括测试数据及预期 的结果。 (3)测试结果: 把每次测试运行的结果归入文 档,如果运行出错,则应产生问题报告, 并且通过调试解决所发现的问题。
《软件工程实用教程》第8_章_软件维护技术
第8 章 軟體維Βιβλιοθήκη 技術8.2 軟體維護類型8.2.1 改正性維護 1. 利用應用軟體包,可開發出比由用戶完全 自己開發的系統可靠性更高的軟體。 2. 結構化技術,用它開發的軟體易於理解和 測試。 3. 防錯性程式設計。把自檢能力引入程式, 通過非正常狀態的檢查,提供審查跟蹤。 4. 通過週期性維護審查,在形成維護問題之 前就可確定品質缺陷。可理解性
第8 章 軟體維護技術
8.2.2 完善性維護 為了滿足日益增長的新要求,需要修改或再 開發軟體,以擴充軟體功能,增強軟體性能, 改進加工效率,提高軟體的可維護性,這些 維護活動稱為完善性維護。 8.2.3 適應性維護 為了使軟體適應新的變化而去修改軟體的維 護活動稱為適應性維護。 8.2.4 預防性維護 為以後進一步使用軟體打下良好基礎的維護 活動稱為預防性維護活動。
第8 章 軟體維護技術
8.4.2 軟體維護的副作用 1.修改代碼的副作用 2.修改數據的副作用 3.修改文檔的副作用
(1)確認維護類型 (2)實施維護 (3)維護評審
第8 章 軟體維護技術
4.整理軟體維護文檔 程式名稱; 使用的程式設計語言; 根源程式語句條數,機器代碼指令條數; 程式安裝的日期; 程式安裝後的運行次數; 與程式安裝後運行次數有關的處理故障次數; 程式改變的層次,名稱和日期; 修改程式所增加的根源程式語句條數; 修改程式所減少的根源程式語句條數;
第8 章 軟體維護技術
8.3 軟體維護技術
8.3.1 軟體維護過程 1.建立維護機構
第8 章 軟體維護技術
2.編寫軟體維護申請報告 軟體變更報告包括的內容: 所需修改變動的性質; 申請修改的優先順序; 為滿足該維護申請報告,所需的工作量(人 員數,時間數); 預計修改後的結果。 3.確定軟體維護工作流程
软件工程(钱乐秋)第08章 基于构件的软件开发
对可复用构件的要求
• • • • • 构件的设计应具有较高的通用程度 构件应易于调整 构件应易于组装 构件必须具有可检索性 构件必须经过充分的测试
复旦大学计算机科学与工程系 软件工程课程
20/41
创建领域构件的设计框架
• 除应遵循已有的设计概念和原则外, 还必须考虑应用领域的特征,例如:
– 标准数据:应该研究应用领域,并标识出标准的全局 数据结构(如文件结构或完整的数据库)。于是所有设 计的构件都可以用这些标准数据结构来刻画 – 标准接口协议:应该建立三个层次的接口协议:构件 内(intramodular)接口、构件外接口以及人机接口
– 程序模板:程序的结构模型可以作为新程序的体系结 构设计的模板
• COM+ • EJB:一种基于Java的构件标准
– 提供了让客户端使用远程的分布式对象的框架 – EJB规约规定了EJB构件如何与EJB容器进行行交互
11/41
复旦大学计算机科学与工程系 软件工程课程
基于构件的软件开发过程
复旦大学计算机科学与工程系 软件工程课程
12/41
领域工程步骤-1
• 领域分析:首先要进行领域分析,收集领域中有代表性 的应用样本,分析应用中的公共部分或相似部分,抽取 该领域的应用体系结构 • 建立领域特定的基准体系结构模型:在领域分析的基础 上,构造该领域的基准体系结构,这个基准体系结构应 是可以裁剪和扩充的,并可供该领域的应用复用 • 标识候选构件:在领域分析和领域基准体系结构模型的 基础上标识该领域的候选构件 • 泛化(generalization)和可变性(variability)分析:提高 其通用性,同时寻找候选构件在不同应用中的变化点 (variation point),通过设置参数、继承或其它手段, 使可变部分局部化
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
(1).在线帮助的使用规定
所有的业务功能(如录入、修改、查询、制单处理、 所有的业务功能(如录入、修改、查询、制单处理、 总账处理、明细账处理)或者较复杂的非业务功能( 总账处理、明细账处理)或者较复杂的非业务功能(如 任意汇总查询、数据通信和传输)中都要提供在线帮助; 任意汇总查询、数据通信和传输)中都要提供在线帮助; 使用按钮操作的窗口,在线帮助使用按钮; 使用按钮操作的窗口,在线帮助使用按钮;使用菜单操 作的窗口,在线帮助使用菜单;对于查询功能, 作的窗口,在线帮助使用菜单;对于查询功能,查询结 果形成前的响应窗口应提供在线帮助。 果形成前的响应窗口应提供在线帮助。
4.3.1 控件级定义
这里讲的控件,是指屏幕界面上的控件, 这里讲的控件,是指屏幕界面上的控件,它是屏 幕窗口中的基本元素,是构件的一种表现形式。 幕窗口中的基本元素,是构件的一种表现形式。
控件1 按钮(Button) 控件1:按钮(Button)
属性:Height=92,Width依具体情况而定; 属性:Height=92,Width依具体情况而定;按钮 依具体情况而定 在窗口右下方或右方排列,当控件中包含按钮时, 在窗口右下方或右方排列,当控件中包含按钮时, 按钮不应和控件外的按钮在同一方向上排列。 按钮不应和控件外的按钮在同一方向上排列。
在线帮助
(2).在线帮助的处理过程 在所有需要帮助的地方,调用一个自定义的公用函数, 在所有需要帮助的地方,调用一个自定义的公用函数, 由该函数负责打开在线帮助。公用函数的格式如下: 由该函数负责打开在线帮助。公用函数的格式如下: GifHelp(String psHelpId) 参数psHelpId 帮助关键字。 参数psHelpId 为帮助关键字。 (3).帮助关键字的构造规范 系统编号( 对象名字( 帮助关键字 = 系统编号( 2位) + | + 对象名字(不 定位)+ | + 语义序号 定位)+ (4).在线帮助函数的调用方法及规定 psHelpId按照上述规定的规范形成 按照上述规定的规范形成。 psHelpId按照上述规定的规范形成。各程序员都要形成 一个积累帮助的文件,文件名规定为Help+程序员名字 一个积累帮助的文件,文件名规定为Help+程序员名字 Help+ 缩写,每调用一次,都要向该文件中加入一行信息, 缩写,每调用一次,都要向该文件中加入一行信息,以 登记调用情况,文件格式的规定,如表8 所示。 登记调用情况,文件格式的规定,如表8-3所示。
软件实现方法
1.新增函数的实现及函数库的管理 . 2.新增存储过程的实现及存储过程库的管理 3.新增类的实现及类库的管理 4.新增构件的实现及构件库的管理 5.新增中间件的实现及中间件的管理 6.部件组装 7.程序设计风格与编程规范 (1).程序设计风格的内容包括: 程序设计风格的内容包括 (1).程序设计风格的内容包括:规范化的程序内部 文档、数据结构的详细说明、清晰的语句结构、 文档、数据结构的详细说明、清晰的语句结构、遵守某 一编程规范。 一编程规范。 (2).编程规范的内容包括:命名规范、界面规范、 编程规范的内容包括 (2).编程规范的内容包括:命名规范、界面规范、 提示及帮助信息规范、热键定义等。 提示及帮助信息规范、热键定义等。
8.1 软件实现方法
软件实现的输入是 详细设计说明书》 输出是 软件实现的输入是《详细设计说明书》,输出是 输入 源程序、目标程序及用户指南。根据“ 源程序、目标程序及用户指南。根据“五个面向 理论” 编程实现的主要方法是“ 理论”,编程实现的主要方法是“面向对象实 因为现在流行的编程语言, 现”。因为现在流行的编程语言,基本上都是面 向对象的语言。 向对象的语言。 面向对象实现” 目标是 按照《 “面向对象实现”的目标是:按照《详细设计说 明书》的要求,从软件公司的函数库、类库、 明书》的要求,从软件公司的函数库、类库、构 件库中挑选有关的零部件, 件库中挑选有关的零部件,遵照软件公司的程序 设计规范,用面向对象的语言,通过穿针引线的 设计规范,用面向对象的语言, 方法,将这些零部件组装起来, 方法,将这些零部件组装起来,分别实现各模块 的功能,从而实现目标系统的功能、性能、接口、 的功能,从而实现目标系统的功能、性能、接口、 界面等要求。 界面等要求。
4.4.1 在线帮助
程序代码与在线帮助的关系采用间接调用方式处理 程序代码与在线帮助的关系采用间接调用方式处理。在 间接调用方式处理。 帮助菜单或按钮中,先调用帮助关键字, 帮助菜单或按钮中,先调用帮助关键字,再根据关键字 查找帮助主题。 查找帮助主题。这样可以使程序代码开发和帮助书写工 作分离,便于开发过程中整体工作的协调安排。 作分离,便于开发过程中整体工作的协调安排。
表8-3 帮助文件的格式
子系统 模块 帮助关键字
在线帮助
(5).帮助关键字与帮助主题的对应关系 为了保证程序中所调用的帮助关键字能够同帮助文件 中帮助主题完全对应, 中帮助主题完全对应,特定义一个保存这种对应关系的 文件,该文件称为对应关系文件, 文件,该文件称为对应关系文件,它作为一个客户端的 配置文件存在,不在数据库中单独列表。 配置文件存在,不在数据库中单独列表。 配置文件名:HLPTOPIC. 配置文件名:HLPTOPIC.INI 格式: 格式: 子系统代码] [子系统代码] HelpTopic, HelpId = HelpTopic,HelpFile 例如: 例如: [ZW] 帮助主题, zw|w_kmzd|kmsr = 帮助主题,帮助文件 zw|w_pzcl|pzsr = 帮助主题,帮助文件 帮助主题,
4.2 源程序设计风格
良好的程序设计风格,能使程序员进行“ 良好的程序设计风格,能使程序员进行“无私程序设 计”,避免程序员与其所产生的代码之间的关系过于密 提高程序代码的规范化程度,使程序代码易读、 切,提高程序代码的规范化程度,使程序代码易读、易 易修改, 懂、易修改,实现程序员之间相互进行程序测试和维护 的目的。 的目的。
实用软件工程
----IT企业软件的开发与管理 IT企业软件的开发与管理 IT 赵池龙 zhaochilong@
第8章 软件实现 章 软件实现
本章导读: 本章导读:
从宏观上讲,软件实现包括详细设计、编程实现、 宏观上讲 软件实现包括详细设计、编程实现、 单元测试和集成测试。 微观上讲 单元测试和集成测试。从微观上讲,软件实现是 指编程和单元测试。本章只讲编程实现方法, 指编程和单元测试。本章只讲编程实现方法,包 括编码风格、界面定义、帮助信息, 括编码风格、界面定义、帮助信息,以及用户指 南书写的参考指南。 南书写的参考指南。 要求理解:编码风格、界面定义、 要求理解:编码风格、界面定义、帮助和提示信 息 要求掌握: 要求掌握: 用户使用手册》 1)《用户使用手册》的编写方法 用户安装手册》 2)《用户安装手册》的编写方法
控件6:图片( 控件 :图片(Picture) )
控件7:标签( 控件 :标签(Tab) )
4.3.2 窗口级定义
窗口级定义包括: 窗口级定义包括: (1)系统主窗口 系统主窗口; (1)系统主窗口; (2)基本参数 又称代码或数据字典) 基本参数( (2)基本参数(又称代码或数据字典)维 护窗口; 护窗口; (3)录入查询修改窗口 录入查询修改窗口; (3)录入查询修改窗口; (4)统计窗口 统计窗口; (4)统计窗口; (5)对话框窗口等等 对话框窗口等等。 (5)对话框窗口等等。 在面向对象的编程语言中, 在面向对象的编程语言中,窗口定义是一 件较简单的事情。 件较简单的事情。
(1).系统主窗口定义 .
(2).基本参数维护窗口定义 .
(3).录入/查询/修改窗口定义 .录入/查询/
录入/查询/修改窗口定义 录入/查询/
选中记录:移动鼠标到该条记录上,并单击它。 (1)选中记录:移动鼠标到该条记录上,并单击它。 浏览记录:用鼠标拖动滚动条, ( 2 ) 浏览记录 : 用鼠标拖动滚动条 , 这样可以看到更 多的参数。 多的参数。 增加记录:按下“插入”按钮, ( 3 ) 增加记录 : 按下 “ 插入 ” 按钮 , 在左边的数据窗 口中将会增加一条空白记录。按下“保存”按钮, 口中将会增加一条空白记录。按下“保存”按钮,就会 将它存入数据库中。 将它存入数据库中。 删除记录:选中将要删除的记录,按下“删除” ( 4 ) 删除记录 : 选中将要删除的记录 , 按下 “ 删除 ” 按钮。按下“保存”按钮,就会从数据库中删除该记录。 按钮。按下“保存”按钮,就会从数据库中删除该记录。 修改记录:选中需要修改的记录,就可以修改。 (5)修改记录:选中需要修改的记录,就可以修改。 放弃修改:对数据进行了改动,允许放弃改动。 ( 6 ) 放弃修改 : 对数据进行了改动 , 允许放弃改动 。 办法是按下右边的“查询”按钮。 办法是按下右边的“查询”按钮。 打印记录:按下“打印”按钮, (7)打印记录:按下“打印”按钮,就得到所需的报 表。
程序设计要求: 程序设计要求:
依照所确定的规范进行程序设计。 (1)依照所确定的规范进行程序设计。 模块本身要高内聚,模块之间要低耦合。 (2)模块本身要高内聚,模块之间要低耦合。 (3)每个程序模块的行数不做规定。对于程序模块中相 每个程序模块的行数不做规定。 对独立性较强的程序块,提炼成为一个函数或构件。 对独立性较强的程序块,提炼成为一个函数或构件。 尽量为程序块加上明确的注释。 (4)尽量为程序块加上明确的注释。对于较复杂的程序 或算法需要有注释文件,并在程序中注明注释文件名, 或算法需要有注释文件,并在程序中注明注释文件名, 在注释文件中注明程序名。 在注释文件中注明程序名。
4.4 帮 助 信 息
帮助信息与用户指南有所不同。前者是联 帮助信息与用户指南有所不同。前者是联 机在线动态帮助 后者是脱机静态指导。 帮助, 脱机静态指导 机在线动态帮助,后者是脱机静态指导。 联机动态帮助与程序运行之间, 联机动态帮助与程序运行之间,存在动态 对应关系。 对应关系。 脱机静态帮助,是一种宏观静态说明。 脱机静态帮助,是一种宏观静态说明。 帮助信息又分为: 帮助信息又分为:在线帮助和提示信息两 部分,此处专门介绍帮助信息的实现方法。 部分,此处专门介绍帮助信息的实现方法。