一、业务流程重组(BPR)与业务流程管理(BPM)
业务流程重组(BPR)
- BPR是对企业的业务流程进行根本性的再思考和彻底性的再设计,从而获得可以用诸如成本、质量、服务和速度等方面的业绩来衡量的显著性的成就。
- 流程:项目的启动、拟定变革计划、建立项目团队、分析目标流程、重新设计目标流程、实施新的设计、持续改进、重新开始。
- 基本原则:以流程为中心的原则、团队管理原则(以人为本)、以客户为导向的原则。
- 基于BPR的系统规划:战略规划、流程规划、数据规划、功能规划、系统实施。
业务流程管理(BPM)
-
BPM是一种以规范化的构造端到端的卓越业务流程为中心,以持续的提高组织业务绩效为目的的系统化方法。
-
PDCA闭环的管理过程:
1)明确业务流程所欲获取的成果
2)开发和计划系统的方法,实现以上成果
3)系统地部署方法,确保全面实施
4)根据对业务的检查和分析以及持续的学习活动,评估和审查所执行的方法。并进一步提出计划和实施改进措施
-
BPM和BPR管理思想最根本的不同就在于流程管理并不要求对所有的流程进行再造。构造卓越的业务流程并不是流程再造,而是根据现有流程的具体情况,对流程进行规范化的设计。
-
流程管理包含三个层面:规范流程、优化流程和再造流程。
表示处理流程的工具
- 图形工具:程序流程图、IPO图、盒图、问题分析图、判定树、PAD图。
- 表格工具:判定表。
- 语言工具:过程设计语言。
二、人机界面设计
-
置于用户控制之下:
1)以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式。
2)提供灵活的交互。
3)允许用户交互可以被中断和撤销。
4)当技能级别增加时可以使交互流水化并允许定制交互。
5)使用户隔离内部技术细节。
6)设计应允许用户和出现在屏幕上的对象直接交互。
-
减少用户的记忆负担:
1)减少对短期记忆的要求。
2)建立有意义的缺省。
3)定义直觉性的捷径。
4)界面的视觉布局应该基于真实世界的隐喻。
5)以不断进展的方式揭示信息。
-
保持界面的一致性:
1)允许用户将当前任务放入有意义的语境。
2)在应用系列内保持一致性。
3)如过去的交互模型已建立起了用户期望,除非有迫不得已的理由,不要改变它。
三、结构化设计
-
分类:概要设计、详细设计
-
概念:是一种面向数据流的方法。
-
原则:自顶向下、逐步求精,信息隐蔽,模块独立(高内聚、低耦合、复杂度)
-
模块四要素:
1)输入和输出
2)处理功能
3)内部数据
4)程序代码
-
原则细化:
1)保持模块的大小适中
2)尽可能减少调用的深度
3)多扇入,少扇出
4)单入口,单出口
5)模块的作用域应该在模块之内
6)功能应该是可预测的
耦合度
- 非直接耦合:两个模块之间没有直接关系,它们之间的联系完全是通过主模块的控制和调用来实现的。
- 数据耦合:一组模块借助参数表传递简单的数据。
- 标记耦合:一组模块通过参数表传递记录信息(数据结构)。
- 控制耦合:模块之间传递的信息中包含用于控制模块内部逻辑的信息。
- 外部耦合:一组模块都访问同一全局简单变量而不是同一全局数据结构,而且不是通过参数表传递该全局变量的信息。
- 公共耦合:多个模块都访问同一个公共数据环境,公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
- 内容耦合:一个模块直接访问另一个模块的内如数据;一个模块不通过正常入口转到另一个模块的内部;两个模块有一部分程序代码重叠;一个模块有多个入口。
内聚度
- 功能内聚:完成一个单一的功能,各个部分协同工作,缺一不可。
- 顺序内聚:处理元素相关,而且必须顺序执行。
- 通信内聚:所有处理元素集中在一个数据结构的区域上。
- 过程内聚:处理元素相关,而且必须按特定的次序执行。
- 瞬时内聚(时间内聚):所包含的任务必须在同一时间间隔内执行。
- 逻辑内聚:完成逻辑上相关的一组任务。
- 偶然内聚(巧合内聚):完成一组没有关系或松散关系的任务。
系统结构/模块结构
- 变换型系统结构
- 事务型系统结构
- 混合型系统结构
四、面向对象设计(设计原则)
- 单一职责原则:设计目的单一的类
- 开放-封闭原则:对扩展开放,对修改关闭
- 李氏(Liskov)替换原则:子类可以替换父类
- 依赖倒置原则:要依赖抽象,而不是具体实现;针对接口编程,不要针对实现编程
- 接口隔离原则:使用多个专门的接口比使用单一的总接口要好
- 组合重用原则:要尽量使用组合,而不是继承关系达到重用目的
- 迪米特(Demeter)原则(最少知识法则):一个对象应该对其他对象有尽可能少的了解
五、面向对象设计(设计模式的概念)
- 架构模式:软件设计中的高层决策,例如C/S架构就属于架构模式,架构模式反映了开发软件系统过程中所作的基本设计决策。
- 设计模式:主要关注软件系统的设计,与具体的实现语言无关。
- 惯用法:是最低层的模式,关注软件系统的设计与实现,实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式,即语言的惯用法。例如引用-计数就是C++语言中的一种惯用法。
六、面向对象设计(设计模式的分类)
-
创建型模式:
1)工厂方法
2)抽象工厂方法
3)原型模式
4)单例模式
5)构建器模式
-
结构型模式:
1)适配器模式
2)桥接模式
3)组合模式
4)装饰模式
5)外观模式
6)享元模式
7)代理模式
-
行为型模式:
1)职责链模式
2)命令模式
3)解释器模式
4)迭代器模式
5)中介者模式
6)备忘录模式
7)观察者模式
8)状态模式
9)策略模式
10)模板方法模式
11)访问者模式
七、面向对象设计(创建型模式)
- 抽象工厂模式(abstract factory method):提供一个接口,可以创建一系列相关或相互依赖的对象,而无需指定它们具体的类。
- 构建器模式(builder):将一个复杂类的表示与其构造相分离,使得相同的构建过程能够得出不同的表示。
- 工厂方法模式(factory method):定义一个创建对象的接口,但由子类决定需要实例化哪一个类。工厂方法使得子类实例化的过程推迟。
- 原型模式(prototype):用原型实例指定创建对象的类型,并且通过拷贝这个原型来创建新的对象。
- 单例模式(singleton):保证一个类只有一个实例,并提供一个访问它的全局访问点。
八、面向对象设计(结构型模式)
- 适配器模式(adapter):将一个类的接口转换成用户希望得到的另一种接口。它使原本不相容的接口得以协同工作。(转换接口)
- 桥接模式(bridge):将类的抽象部分和它的实现部分分离开来,使它们可以独立地变换。(继承树拆分)
- 组合模式(composite):将对象组合成树型结构以表示“整体-部分”的层次结构,使得用户对单个对象和组合对象的使用具有一致性。树型目录结构
- 装饰模式(decorator):动态地给一个对象添加一些额外的职责。它提供了用子类扩展功能的一个灵活的替代,比派生一个子类更加灵活。(附加职责)
- 外观模式(facade):定义一个高层接口,为子系统中的一组接口提供一个一致的外观,从而简化了该子系统的使用。(对外统一接口)
- 享元模式(flyweight):提供支持大量细粒度对象共享的有效方法。
- 代理模式(proxy):为其他对象提供一种代理以控制这个对象的访问。
九、面向对象设计(行为型模式)
- 职责链模式(chain of responsibility):通过给多个对象处理请求的机会,减少请求的发送者与接收者之间的耦合。将接收对象链接起来,在链中传递请求,直到有一个对象处理这个请求。(传递职责)
- 命令模式(command):将一个请求封装为一个对象,从而可用不同的请求对客户进行参数化,将请求排队或记录请求日志,支持可撤销的操作。(日志记录,可撤销)
- 解释器模式(interpreter):给定一种语言,定义它的文法表示,并定义一个解释器,该解释器用来根据文法表示来解释语言中的句子。
- 迭代器模式(iterator):提供一种方法来顺序访问一个聚合对象中的各个元素,而不需要暴露该对象的内部表示。
- 中介者模式(mediator):用一个中介对象来封装一系列的对象交互。它使各对象不需要显式地相互调用,从而达到低耦合,还可以独立地改变对象间的交互。(不直接引用)
- 备忘录模式(memento):在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,从而可以在以后将该对象恢复到原先保存的状态。
- 观察者模式(observer):定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动更新。
- 状态模式(state):允许一个对象在其内部状态改变时改变它的行为。(状态变成类)
- 策略模式(strategy):定义一系列算法,把它们一个个封装起来,并且使它们之间可互相替换,从而让算法可以独立于使用它的用户而变化。(多方案切换)
- 模板方法模式(template method):定义一个操作中的算法骨架,而将一些步骤延迟到子类中,使得子类可以不改变一个算法的结构即可重新定义算法的某些特定步骤。
- 访问者模式(visitor):表示一个作用于某对象结构中的各元素的操作,使得在不改变各元素的类的前提下定义作用于这些元素的新操作。