如何增强软件的可维护性及可扩展性
个人认为将当前情况下,行为分配给农场主既有利于可扩展又有利于维护性。
从语义上分析:挤奶是行为,本例中只有农场主具有该行为,奶牛语义上不应该具备该行为,奶牛只能返回相关属性,让农场主判定是否能够挤奶,挤奶量等等。
无论奶牛如何扩展、甚至农场主扩展,都可以依赖抽象(当然不考虑双分发问题),具备较高的扩展性。
同时维护点少,如果分配给奶牛,那么如果奶牛的挤奶行为出现差错,则可能需要从顶层至底层修改奶牛的行为。
而分配给农场主,则出错仅需在挤奶这个行为范围内进行修改。
题外话:当然复杂情况下,维护性不好判断,也就是说,前提是如果系统扩展至一定层次,那么农场主挤奶行为可能会十分复杂,那么它的维护性远远低于分配给奶牛。
如何提高系统可维护性
软件的可维护性是指维护人员为纠正软件系统出现的错误或缺陷,以及为满足新的要求而理解、修改和完善软件系统的难易程度。
提高可维护性是决定软件工程方法论所有步骤的关键目标。
从下面五个方面来阐述如何提高软件的可维护性: 1.建立明确的软件质量目标 如果要程序满足可维护性七个特性的全部要求,那么要付出很大的代价,甚至是不现实的,但有些可维护性是相互促进的,因此要明确软件所追求的质量目标。
2.使用先进的软件开发技术和工具 利用先进的软件开发技术能大大提高软件质量和减少软件费用。
面向对象的软件开发方法就是一个非常实用而强有力的软件开发方法,用面向对象方法开发出来的软件系统,稳定性好,比较容易修改,比较容易理解,易于测试和调试,因此,可维护性好。
3.建立明确的质量保证 质量保证是指为提高软件质量所做的各种检查工作。
质量保证检查是非常有效的方法,不仅在软件开发的各阶段中得到了广泛应用,而且在软件维护中也是一个非常主要的工具。
为了保证可维护性,以下四类检查是非常有用的: (1)在检查点进行检查。
(2)验收检查。
(3)周期性的维护检查。
(4)对软件包的检查。
4.选择可维护的语言 程序设计语言的选择对维护影响很大。
低级语言很难掌握,很难理解,因而很难维护。
一般来说,高级语言比低级语言更容易理解,第四代语言更容易理解,容易编程,程序容易修改,改进了可维护性。
5.改进程序的文档 程序文档是对程序功能、程序各组成部分之间的关系、程序设计策略、程序实现过程的历史数据等的说明和补充。
程序文档对提高程序的可阅读性有重要作用。
为了维护程序,人们必须阅读和理解程序文档。
可维护性的可维护性
根据Boehm模型,通常影响软件可维护性的因素有可理解性、可测试性和可修改性。
1.可理解性可理解性是指维护人员理解软件的结构、接口、功能和内部过程的难易程度。
2.可测试性可测试性是指测试和诊断软件错误的难易程度。
3.可修改性可修改性是指修改软件的难易程度。
为了提高软件的可维护性,在软件生命周期的各个阶段都必须考虑维护问题。
先进的软件工程方法,是软件可维护的基础保证。
面向对象学的对象封闭机制、消息通信机制、继承机制和多态机制从根本上提高了软件的可理解性、可测试性和可修改性。
结构化设计的几条主要原则:模块化、信息隐蔽、高内聚、低耦合等,对于提高软件的可理解性、可维护性和可修改性也都有很重要的作用。
另外,书写详细正确的文档、书写源文件的内部注解、使用良好的编程语言、具有良好的程序设计风格,也有助于提高软件的可理解性。
使用先进的测试工具、保存以前的测试过程和测试用例,则有助于提高软件的可测试性。
软件的可维护性与哪些因素有关?在软件开发过程中应该此案去哪些措...
程序就不写了。
要写一个体现出接口有点的程序有点多。
我以前做个一个小系统,有点体现。
是一个在线考试系统。
刚做的时候没有在线功能,定义了一个考试接口。
由本地考试的实现类来实现这个接口。
在配置文件中配置了接口创建的对象是该实现类的对象。
后来换成在线版本的,又另外一个实现类来实现这个接口。
只需要将配置文件中接口创建对象的实现类名字改一下就可以了。
业务代码一句都没有改变,因为代码里创建的是接口的对象,实例化的实现类是通过配置文件读取的。
小系统用这个显不出优势。
大点的项目很多人一起写代码,如果要一项一项修改的话很麻烦,因为有人员的流动,不知道前面的那个人在哪里添加了这个对象的引用。
没有接口的话维护起来要做的工作量很大。
软件的可维护性与哪些因素有关
内聚、局部化、控制域与作用域的关系等等。
维护人员在正确理解一个程序之前根本不可能修改它。
如果是改正性维护,还必须预先进行调试以确定故障、可用的测试工具和调试工具,以及以前设计的测试过程也都是非常重要的。
维护人员应该能够得到在开发阶段用过的测试方案、功能和内部过程的难易程度。
模块化、详细的设计文档、结构化设计、源代码内部的文档和良好的高级程序设计语言等等,都对改进软件的可理解性有重要贡献。
2.可测试性诊断和测试的难易程度主要取决于软件容易理解的程度、改动和改进这个软件的难易程度。
提高可维护性是支配软件工程方法论所有步骤的关键目标。
维护就是在软件交付使用后进行的修改,修改之前必须理解修改的对象,修改之后应该进行必要的测试,以保证所做的修改是正确的,都影响软件的可修改性。
上述三个可维护性因素是紧密相关的软件可维护性的因素,软件可维护性可以定性地定义为。
良好的文档对诊断和测试是至关重要的。
因此,影响软件可维护性的因素主要有下述三个.可理解性软件可理解性表现为外来读者理解软件的结构、接口,以便进行回归测试。
在设计阶段应该尽力把软件设计成容易测试和容易诊断的。
3.可修改性软件容易修改的程度和软件设计原理和规则直接有关。
耦合:维护人员理解、改正。
1;如果不能进行完善的诊断和测试,则表面正确的修改可能引进其他故障。
此外,软件结构 展开
如何提高软件的质量?
一、什么是质量? 作为软件产品的销售人员,市场人员或维护人员经常会受到客户这样那样的指责或抱怨,客户说:你们产品的质量太差,不稳定等等。
那么什么是质量呢?我们该如何来衡量质量呢? 质量具有三个维度: ?? 符合目标。
目标是客户所定义的,符合目标即判断我们是不是在做需要做的事情。
?? 符合需求。
即产品是不是在做让它做的事情。
?? 符合实际需求。
实际的需求包括用户明确说明的和隐含的需求。
ISO 关于质量的定义表示如下: “ 一个实体(产品或服务)的所有特性,基于这些特性可以满足明显的或隐含的需要。
” 注意,在这个定义中包含明显的需求和隐含的需求。
而往往我们会忽略隐含的需求。
因此在控制一个产品的质量的过程中必须关注这些隐含的需求,并给予应有的验证。
另一方面因为我们的产品是为客户提供服务的,因此凡是不满足客户需求的,我们都认为是一个失效( failure )。
所以我们的产品必须始终围绕着客户的需求进行开发和验证。
这里我们谈到客户,其实在一个软件的需求收集过程中需要关注客户和用户。
而我们经常会忽略客户与用户之间的区别。
那么谁是客户?谁是用户呢?简单的来说,客户是真正能够决定是否购买你软件的人,而用户是实际使用软件的人。
了解了这个区别,对于你在分析需求的重要性的时候就可以进行参考。
同时在产品质量验证的时候也可以做出不同的权衡。
另一方面我们在考虑我们用户需求的时候,往往只考虑了实际使用软件的人员,而忽略了其它一些人员对软件的要求或对软件造成的潜在竞争,这包括维护人员的要求、系统管理人员的要求、软件上下游人员的要求、先前版本的情况、市场上竞争对手的软件情况等。
每个人提到质量的时候,经常会遇到下列矛盾,在这些矛盾中隐含着对质量的承诺【 5 】: ?? 质量需要一个承诺,尤其是高层管理者的承诺。
但为了得到质量,高层管理者必须和其雇用的员工进行紧密合作; ?? 许多人相信没有缺陷的产品和服务是不可能的。
但是控制在一定级别的缺陷数是正常并可接受的; ?? 质量经常是和成本紧密联系在一起,一个高质量的产品同时也意味着高投入。
这是设计的质量和一致性质量的一个矛盾; ?? 一个高的质量要求需求规格说明书足够详细,以便产品可以根据这些规格说明书进行定量的分析。
然而许多组织没有能力或者不愿意产生如此详细程度的规格说明书; ?? 技术人员经常相信规范和标准会束缚他们的创造力,因此就不遵照标准做事。
然而如果要得到高质量的产品,就必须遵循良好定义的标准和过程。
二、流程对质量的贡献 好了,既然已经了解了什么是质量,那么怎么才能改进软件产品的质量呢?从一个企业的长远发展来看,首先应当从流程抓起,规范软件产品的开发过程。
这是一个软件企业从小作坊的生产方式向集成化、规范化的大公司迈进的必经之路,也是从根本上解决质量问题,提高工作效率的一个关键手段。
软件产品的开发同其它产品(如汽车)的生产有着共同特性,即需要按一定的过程来进行生产。
在工业界,流水线生产方式被证明是一种高效且能够比较稳定地保证产品质量的一种方式。
通过这种方式,不同的人员被安排在流程的不同位置,最终为着一个目标共同努力,这样可以防止人员工作间的内耗,极大的提高工作效率。
并且由于其过程来源于成功的实例,因此其最终的产品质量能够满足过程所设定的范围要求。
软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中,这就形成了软件工程过程,简单的说就是开发流程。
无论做什么事情,都有一个循序渐进的过程,从计划到策略再到实现。
软件流程就是按照这种思维来定义开发过程,它根据不同的产品特点和以往的成功经验,定义了从需求到最终产品交付的一整套流程。
流程告诉我们该怎么一步一步去实现产品,可能会有那些风险,如何去避免风险等等。
由于流程来源于成功的经验,因此,按照流程进行开发可以使得我们少走弯路,并有效的提高产品质量,提高用户的满意度。
目前流行的流程方法有很多种,不同的过程模型适合于不同类型的项目。
瀑布模型是应用的最为广泛的一种模型,也是最容易理解和掌握的模型,然而它的缺陷也是显而易见的。
遗漏的需求或者不断变更的需求会使得该模型无所适从。
然而,对于那些容易理解但很复杂的项目,采用瀑布模型会是比较适合的,因为你可以按部就班的去处理复杂的问题。
在质量要求高于成本和进度要求的时候,该模型表现的尤其突出。
螺旋模型是也是一个经典模型,它关注于发现和降低项目的风险【 8 】。
螺旋型项目从小的规模开始,然后探测风险,制定风险控制计划,接着确定下一步项目是否还要继续,然后进行下一个螺旋的反复。
该模型的最大优点就是随着成本的增加,风险程度随之降低。
然而螺旋模型的缺点是比较复杂,且需要管理人员有责任心,专注以及有管理方面经验。
RUP ( Rational Unified Process )是 Rational 公司提出的一套开发过程模型,它是一个面向对象软件工程的通用业务流程【 9 】。
它描述了一系列相关的软件工程流程,它们具有相同的结构,...
就如何利用面向对象的软件开发方法来开发软件心得体会
面向对象技术是软件技术的一次革命,在软件开发史上具有里程碑的意义。
随着OOP(面向对象编程)向OOD(面向对象设计)和OOA(面向对象分析)的发展,最终形成面向对象的软件开发方法 OMT(LbjectModellingTechnique)。
这是一种自底向上和自顶向下相结合的方法,而且它以对象建模为基础,从而不仅考虑了输入、 输出数据结构,实际上也包含了所有对象的数据结构。
所以OMT彻底实现了PAM没有完全实现的目标。
不仅如此,OO技术在需求分析、可维护性和可靠性这三 个软件开发的关键环节和质量 指标上有了实质性的突破,彻底地解决了在这些方面存在的严重问题,从而宣告了软件危机末日的来临。
自底向上的归纳 OMT的第一步是从问题的陈述入手,构造系统模型。
从真实系统导出类的体系,即对象模型包括类的属性,与子类、父类的继承关系,以及类之间的关 联。
类是具有相似属性和行为的一组具体实例(客观对象)的抽象,父类是若干子类的归纳。
因此这是一种自底向上的归纳过程。
在自底向上的归纳过程中,为使子 类能更合理地继承父类的属性和行为,可能需要自顶向下的修改,从而使整个类体系更加合理。
由于这种类体系的构造是从具体到抽象,再从抽象到具体,符合人类 的思维规律,因此能更快、更方便地完成任务。
这与自顶向下的Yourdon方法构成鲜明的对照。
在Yourdon方法中构造系统模型是最困难的一步,因为 自顶向下的“顶”是一个空中楼阁,缺乏坚实的基础,而且功能分解有相当大的任意性,因此需要开发人员有丰富的软件开发经验。
而在OMT中这一工作可由一般 开发人员较快地完成。
在对象模型建立后,很容易在这一基础上再导出动态模型和功能模型。
这三个模型一起构成要求解的系统模型。
自顶向下的分解 系统模型建立后的工作就是分解。
与Yourdon方法按功能分解不同,在OMT中通常按服务(Service)来分解。
服务是具有共同目标的相关 功能的集合,如I/O处理、图形处理等。
这一步的分解通常很明确,而这些子系统的进一步分解因有较具体的系统模型为依据,也相对容易。
所以OMT也具有自 顶向下方法的优点,即能有效地控制模块的复杂性,同时避免了Yourdon方法中功能分解的困难和不确定性。
OMT的基础是对象模型 每个对象类由数据结构(属性)和操作(行为)组成,有关的所有数据结构(包括输入、输出数据结构)都成了软件开发的依据。
因此Jackson方法 和PAM中输入、输出数据结构与整个系统之间的鸿沟在OMT中不再存在。
OMT不仅具有Jackson方法和PAM的优点,而且可以应用于大型系统。
更重 要的是,在Jackson方法和PAM方法中,当它们的出发点——输入、输出数据结构(即系统的边界)发生变化时,整个软件必须推倒重来。
但在OMT中系 统边界的改变只是增加或减少一些对象而已,整个系统改动极小。
需求分析彻底 需求分析不彻底是软件失败的主要原因之一。
即使在目前,这一危险依然存在。
传统的软件开发方法不允许在开发过程中用户的需求发生变化,从而导致种种问题。
正是由于这一原 因,人们提出了原型化方法,推出探索原型、实验原型和进化原型,积极鼓励用户改进需求。
在每次改进需求后又形成新的进化原型供用户试用,直到用户基本满意,大大提高了软件的 成功率。
但是它要求软件开发人员能迅速生成这些原型,这就要求有自动生成代码的工具的支持。
OMT彻底解决了这一问题。
因为需求分析过程已与系统模型的形成过程一致,开发人员与用户的讨论是从用户熟悉的具体实例(实体)开始的。
开发人员必须搞清现实系统才能导出系统模型,这就使用户与开发人员之间有了共同的语言,避免了传统需求分析中可能产生的种种问题。
可维护性大大改善 在OMT之前的软件开发方法都是基于功能分解的。
尽管软件工程学在可维护方面作出了极大的努力,使软件的可维护性有较大的改进。
但从本质上讲,基于功能分解的软件是不易 维护的。
因为功能一旦有变化都会使开发的软件系统产生较大的变化,甚至推倒重来。
更严重的是,在这种软件系统中,修改是困难的。
由于种种原因,即使是微小的修改也可能引入 新的错误。
所以传统开发方法很可能会引起软件成本增长失控、软件质量得不到保证等一系列严重问题。
正是OMT才使软件的可维护性有了质的改善。
OMT的基础是目标系统的对象模型,而不是功能的分解。
功能是对象的使用,它依赖于应用的细节,并在开发过程中不断变化。
由于对象是客观存在的,因此当需求变化时对象的性质要比对象的使用更为稳定,从而使建立在对象结构上的软件系统也更为稳定。
更重要的是OMT彻底解决了软件的可维护性。
在OO语言中,子类不仅可以继承父类的属性和行为,而且也可以重载父类的某个行为(虚函数)。
利用这 一特点,我们可以方便地进行功能修改:引入某类的一个子类,对要修改的一些行为(即虚函数或虚方法)进行重载,也就是对它们重新定义。
由于不再在原来的程 序模块中引入修改,所以彻底解决了软件的可修改性,从而也彻底解决了软件的可维护性。
OO技术还提高了软件的可靠性和健壮性。
转载请注明出处51数据库 » 提高软件可维护性的方法