需求分析与系统设计课件1编程范式.pptVIP

* * 软件实体的可变性？ “软件产品扎根于文化的母体中，如各种应用、用户、自然及社会规律、计算机硬件等等。后者持续不断地变化着，这些变化无情地强迫着软件随之变化” 目前的软件产品（它是对某一瞬间/阶段需求的模拟），事实上是以不可变应对可变性。 从这一角度看，在软件产品自身具备适应性之前（病毒？），依靠程序员帮助它们应对可变性 . 补丁 新版本 * * ②可维护性 定义：软件能够被理解、校正、适应及增强功能的容易程度。 软件发布后的变更被称为“ 软件维护”。 这些软件变更包含了 1、更多的新增功能（以适应用户的新的愿望）； 2、对设计缺陷的修复。 * * 维护的代价 在2002年12期的The Rational Edge杂志中[1]，Walker Royce列出了两条重要的统计数据： 在开发上每投入1元，就将在维护上花费2元。令人惊讶的是，维护一个系统的代价是开发系统的2倍。 在软件开发过程中，大约只有15％的精力是用于编程。 这里的结论是： 系统开发的核心是其可维护性。 分析与设计远比编程重要和费时；[1] Kirk Knoernschild，《Java设计：对象、UML和过程》，人们邮电出版社，2003-4，p2 * * 好的可维护性？ 很强的可读性 Martin Fowler：“Any fool can write code that a computer can understand. Good programmers write code that humans can understand”。 注释、文档的重要性。 设计没有坏味道 * * 设计中的坏味道 僵硬（Rigidity 刚性，反义词flexible，有弹性、柔性）：设计（的软件实体）难以改变。现象上看，设计上的单个变化将引起依赖模块[产生]级联变化（a cascade of changes、连锁反应），每种改变都会影响到系统中太多太多其他部分。 脆弱(fragile，反义词robust鲁棒的)：设计一碰就倒。作了一个变动，[导致]系统中某些（甚至意想不到的）部分会出错。新问题经常出现于与被改变的区域没有概念上关联的地方，于是解决那些问题导致了甚至更多的问题，而维护工作开始变得像一条狗追赶自己的尾巴。 不动(immobile)：不易复用的设计。它难以复用于别的应用程序，由于它不能从当前应用中解脱出来。从复用的角度看，设计中想要的部分与该设计中不想要的部分分开必须做大量的（太多的）工作。虽然可维护性和可复用性是两个独立的目标，但是它们一般而言是正相关的。 …… * * 相互依赖(interdependence) 坏味道的原因，在于该设计中模块的相互依赖(interdependence)。 所谓倚赖，从BlueJ中可以直观地看出：如果你修改了一个类A的某些代码(如加一个空格)，如果其他的类也需要重新编译，那么这些类都倚赖于A。 “11.10 目标上（和开发策略上）的一些正常变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。” 措施是： 使用关系中，依赖于抽象类型； 继承关系中，尽可能的避免实现继承 (extends 关系)，而采用接口继承（implements关系）。 * * ③概念完整性 conceptual integrity 开发团队的组织和领导，涉及软件管理学。其中，项目管理是软件工程研究的重要领域，包括可行性研究、时间和资金预算（成本估算）、开发过程的选择（RUP或XP）和质量保证 。 “系统开发项目管理是信息系统建设中的重要保障。主要内容除进度、质量和成本管理，还包括人员管理、版本管理、知识管理、团队管理等。项目管理应用软件的使用将会有助于管理工作的进行。项目管理的重点是要在进度、质量、成本中取得一个平衡点和最佳值”。 软件管理学的第一要务：保证系统的概念完整性 。 『法国城市兰斯（Reims），其风格的一致和完整性来自8 代拥有自我约束和牺牲精神的建筑师们，他们每一个人牺牲了自己的一些创意，以获得纯粹的设计。』 * * 唯一的设计理念 宁可不添加一些七七八八的功能（anomalous features），也应该保证整个系统体现的是完整的一整套设计思路。 在整个开发过程中应该有一个真正的产品负责人（或者称之为总设计师），负责产品的整体结构设计、各模块的交互关系、功能设计和实现方案的取舍。 概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想。 * * 保证概念完整性 大型软件系统强调对于文档的重视， 极限编程（Extreme Programming）则强调“沟通” 这是《人月神话》关注的主要问题。 * * ④理论和方法支持 1986年，Frederick P. Brooks