瀑布模型
适用于需求明确的项目
演化模型
增量模型
螺旋模型
适合大型的系统
原型模型
喷泉模型
V模型
快速应用开发
构件组装模型/基于构件的开发方法
统一过程/统一开发方法
敏捷开发方法
模型驱动的开发方法
基于架构的开发方法
类图(class diagram):类图描述一组类、接口、协作和它们之间的关系
对象图(object diagram): 对象图描述一组对象和它们之间的关系。对象图描述了在类图中所建立的事务实例的静态快照。
架构模式:软件设计中的高层决策,例如C/S结构就属于架构模式,架构模式反映了开发软件系统过程中所作的基本设计决策
设计模式:主要关注软件系统的设计,与具体的实现语言无关
惯用法:最低层的模式,关注软件系统的设计与实现,实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式,即语言的惯用法。例如引用计数就是C++语言中的一种惯用法
创建型模式:创建对象
1、工厂方法(Factory Method):动态生产对象。定义一个创建对象的接口,但由子类决定需要实例化哪个类。工厂方法使得子类实例化的过程推迟。
2、抽象工厂(Abstract Factory):生产成系列对象。 提供一个接口,可以创建一系列相关或相互依赖的对象,而无需指定它们具体的类。
3、原型(Prototype):克隆对象。用原型实例指定创建对象的类型,并且通过拷贝这个原型来创建新的对象。
4、构建器(Builder):复杂对象构造。将一个复杂类的表示与其构造相分离,使得相同的构建过程能够得出不同的表示。
5、单例模式(Singleton):单实例。保证一个类只有一个实例,并提供一个访问它的全局访问点。
结构型模式:更大的结构
6、适配器(Adapter):转换接口。将一个类的接口转换成用户希望得到的另一种接口。它使原本不相容的接口得以协同工作。
7、桥接(Bridge):继承树拆分。将类的抽象部分和它的实现部分分离开来,使它们可以独立的变化。
8、组合(Composite):树形目录结构。将对象组合成树型结构以表示”整体-部分“的层次结构,使得用户对单个对象和组合对象的使用具有一致性。
9、装饰(Decorator):动态附加职责。动态地给一个对象添加一些额外地职责。它提供了用子类扩展功能地一个灵活地替代,比派生一个子类更加灵活。
10、外观(Facade):对外统一接口。定义一个高层接口,为子系统中地一组接口提供一个一致地外观,从而简化了该子系统地使用。
11、享元(Flyweight):汉字编码。提供支持大量细粒度对象共享地有效方法。
12、代理(Proxy):快捷方式。为其他对象提供一种代理以控制这个对象地访问。
Spring AOP中的代理使用的默认策略:
行为型模式:(交互及职责分配)
13、职责链(Chain of Responsibility):传递职责。通过给多个对象处理请求地机会,减少请求地发送者与接收者之间地耦合。将接受对象链接起来,在链中传递请求,直到有一个对象处理这个请求。
14、命令(Command):日志记录,可撤销。将一个请求封装为一个对象,从而可用不同地请求对客户进行参数化,将请求排队或记录请求日志,支持可撤销地操作。
15、解释器(Interpreter):虚拟机地机制。给定一种语言,定义它的文法表示,并定义一个解释器,该解释器用来根据文法表示来解释语言中的句子。
16、迭代器(Iterator):数据集。提供一种方法来顺序访问一个聚合对象中的各个元素,而不需要暴露该对象的内部表示。
17、中介者(Mediator):不直接引用。用一个中介对象来封装一系列的对象交互。它使各个对象不需要显式地相互调用,从而达到低耦合,还可以独立地改变对象间地交互。
18、备忘录、快照(Memento):游戏存档。在不破坏封装地前提下,捕获一个对象地内部状态,并在该对象之外保存这个状态,从而可以在以后将该对象恢复到原先保存地状态。
19、观察者(Observer):联动。定义对象间地一种一对多地依赖关系,当一个对象地状态发生改变时,所有依赖于它地对象都得到通知并自动更新。
20、状态(State):状态变成类。允许一个对象在其内部状态改变时改变它地行为。
21、策略(Strategy):多方案切换。定义一系列算法,把他们一个个封装起来,并且使它们之间可以相互替换,从而让算法可以独立于使用它地用户而变化。
22、模板方法(Template Method):框架。定义一个操作中的算法骨架,而将一些步骤延迟到子类中,使得子类可以不改变一个算法的结构即可重新定义算法的某些特定步骤。
23、访问者(Visitor):数据与操作分离。表示一个作用于某对象结构中的各个元素的操作,使得在不改变各个元素的类的前提下定义作用于这些元素的新操作。
加粗的表示可以是类模式,也可以是对象模式;其他表示只是对象模式
红色字体表示速记关键字
软件调试方法:
软件调试与测试的区别:
淘汰策略:遗留系统的技术含量较低,且具有较低的业务价值。对遗留系统的完全淘汰是企业资源的根本浪费,系统分析师应该善于”变废为宝“,通过对遗留系统功能的理解和借鉴,可以帮助新系统的设计,降低新系统开发的风险。
继承策略:遗留系统的技术含量较低,已经满足企业运作的功能或性能要求,但具有较高的商业价值,目前企业的业务尚紧密依赖该系统。对这种遗留系统的演化策略为继承。在开发新系统时,需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性,新老系统必须并行运行一段时间,再逐渐切换到新系统上运行。
改造策略:遗留系统具有较高的业务价值,基本上能够满足企业业务运作和决策支持的需要。这种系统可能建成的时间还很短,对这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求。对遗留系统本身不做改变,数据模型的改造是指将遗留系统的旧数据模型向新的数据模型的转化。
集成策略:遗留系统的技术含量较高,但是其业务价值较低,可能只是完成某个部门或者子公司的业务管理。这种系统再各自的局部领域里工作良好,但对于整个企业来说,存在多个这样的系统,不同的系统基于不同的平台、不同的数据模型,形成了一个个信息孤岛,对这种遗留系统的演化策略为集成。
正确性维护:改正正在系统开发阶段已发生而系统测试阶段尚未发现的错误。
适应性维护:使应用软件适应信息技术变化和管理需求变化而进行的修改。企业外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。
完善性维护:扩充功能和改善性能而进行的修改。对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
预防性维护:改进应用软件的可靠性和维护性,为了适应未来的软硬件环境的变化,应主动增加预防性的新的功能,以使用系统适应各类变化而不被淘汰。如将专用报表功能改成通用报表生成功能,以适应将来报表格式的变化。