面向构件软件过程
软件的发展
• 大约每隔5至10年,软件界就会重定义“问题”,
• 将其焦点从“产品”转移到“过程”。
– Roger S. Pressman《软件工程:实践者的研究方法》
• Stephen R. Palmer曾指出,“好的过程清晰地定
义任务。任务焦点放在结果上而不是细节上……”。
• 因为具体实践是鲜活多变的,定义太多关乎“How”
的细节,不利于过程的适应性;而只有将过程划
分成不同的子任务,并清晰定义每个任务的目标
结果(What),才能更切入本质的东西,从而使
项目既可以有效地进行,又能适应一些非常事件
及环境的变化。
• 我们对面向构件软件过程的阐述,将贯彻
上述“两个强调”原则——即强调“任务”及其
产出的“核心工作产品”。在此基础上,再进
一步讲清楚各个任务之间的依从关系、以
及各个核心工作产品之间的跟踪关系。
深入理解软件过程
• 不同的软件过程(如RUP和XP),过程模型会有
很大不同。为了考察软件过程的共性,我们来研
究软件过程的元模型。
软件过程元模型(图片来源:
Software Process Engineering
Metamodel, version 1.1)
• 软件过程元模型显示了任何软件过程都必不可少的角色、
活动、工作产品的概念。
– 角色是对个人或作为开发团队的一组人员职责的规定;
• 角色的职责,具体体现在他执行的活动和负责的工作产品上。
– 活动是角色执行的工作单元;
• 工作产品是由活动生产出来的——工作产品是活动的输出:比如制定
《编码
规范
编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载
》。
– 而工作产品是工作的成品或半成品。
• 然而,活动本身也可能以工作产品为输入——活动可能要求使用工作
产品:比如编码活动要参考《编码规范》。
• 当然,工作产品可以既是活动的输入又是它的输出——活动修改工作
产品:比如修改《编码规范》。
面向构件软件过程的主要阶段
• 面向构件的软件过程分为如下五个主要阶段:
– 需求阶段:
• 捕获需求,识别业务构件,归纳业务构件需求;
– 分析与高层
设计
领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计
阶段:
• 分析业务构件,识别服务构件,架构设计,归纳服务构件需求;
– 并行开发与测试阶段:
• 开发并测试服务构件、业务构件、应用系统;
– 提交、发布与部署阶段:
• 提交服务构件、业务构件到构件库,发布应用系统,部署应用系统;
– 应用管理:
• 对上线系统及其中的运行构件实施例行管理,以及各种突发情况的处
理维护。
面向构件软件过程的核心工作产品
• 对于任何软件方法论而言,工
作产品都是影响重大的——因
为产出工作产品的数量直接决
定了软件过程的敏捷程度。
• 而具体项目的实施,其规范程
度和敏捷程度应根据具体项目、
具体团队情况而定。因此,我
们强调对本软件过程至关重要
的核心工作产品,至于还需采
用哪些外围工作产品,可由项
目团队根据自身情况自行决定。
面向构件的软件过程的核心工作产品
• 业务构件需求
• 可复用业务构件列表
• 系统架构文档
• 业务构件设计文档
• 服务构件需求
• 可复用服务构件列表
• 服务构件
• 业务构件
• 应用系统
跟踪关系
• 下面说明这些概念之间的跟踪关系在面向
构件的软件过程中的体现
面向构件软件过程的主要角色
• 需求分析师
• 领域专家
• 架构设计师
• 开发人员
• 测试人员
• 构件库管理员
• 发布经理
• 工程实施人员
• 应用管理员
• 项目经理
需求分析师
• 需求分析师是需求捕获与整理方面的专家;并且
他应当熟悉面向构件的需求阶段工作的独特之
处,最终将需求归纳为业务构件需求。
• 需求分析师的主要职责:
– 推动需求捕获工作
– 领导领域专家进行需求捕获和整理
– 归纳业务构件需求
– 需求归档
领域专家
• 既然面向构件方法非常强调企业知识的积累,那么领域专
家在该方法中的重要性,就比在一般的方法中要来得大;
充分发挥领域专家的作用,目的是更好地把他们头脑中的
知识最终转化为商业价值。
• 领域专家的职责:
– 和需求分析师紧密配合,完成需求捕获工作
– 配合识别业务构件,尽量保证其符合特定业务领域的惯例
– 参与业务构件的评审
– 参与系统级的验收测试
架构设计师
• 架构设计师在应用系统的组织方式、构成要素、行
为契约、架构风格等方面做出决策,从而为后续开
发提供明确有力的指导。
• 架构设计师的职责:
– 业务构件分析
– 应用架构设计
– 按照面向构件的思想,识别构件、确定构件接口和行为
– 决定服务构件需求
– 负责架构归档
– 协助项目经理制定并行开发
计划
项目进度计划表范例计划下载计划下载计划下载课程教学计划下载
开发人员
• 如前所述,面向构件的软件过程提倡“为复用而生
产,为使用而组装”。因此,开发人员会有进一步
的角色分化(构件开发者和应用组装者)。
• 总体而言,开发人员的职责为:
– 服务构件的详细设计与实现
– 对服务构件进行单元测试
– 实现业务构件
– 将业务构件组装成应用系统
测试人员
• 构件是为复用而开发的,测试人员的工作将凝聚
在构件之中,随着构件不断地被复用而发挥价值。
• 测试人员的职责:
– 对业务构件进行集成测试
– 对软件系统进行系统测试(包含功能测试、非功能专
项测试、验收测试等)
构件库管理员
• 由于面向构件软件过程对构件复用的突出强调,所有构件
库管理员——作为构件积累专家——从需求阶段就会参与
可复用资产的分析工作,并且在后续阶段提供持续支持。
• 构件库管理员的职责:
– 配合需求分析师进行可复用业务构件分析、确定业务构件需求
– 配合架构设计师进行可复用业务构件分析、确定服务构件需求
– 主持服务构件和业务构件的提交评审
– 主持服务构件和业务构件的提交工作
– 负责构件的完整性,将构件的相关文档和说明等工作产品一并入
库
– 构件库的日常管理和维护
发布经理
• 面向构件的软件过程对持续集成的天然支持,对
外表现为增量发布。发布经理负责具体的增量发
布工作。
• 发布经理的职责:
– 决定发布内容(特定子版本应用系统、文档和手册等)
并实施发布
– Release Notes的编写者
– 产品包装等发布相关事宜
工程实施人员
• 最终的应用系统,在何种基础设施的环境之下进
行部署会有很大不同,工程实施人员负责该项工
作。
• 工程实施人员的职责:
– 辅助用户方进行运行环境的决策
– 实施面向构件应用系统的部署
应用管理员
• 如您所知,维护和管理阶段,在软件的生命周期
中是最长的一个阶段。应用管理员负责相关工作。
• 系统管理员的职责:
– 初始化
– 配置
– 监控
– 诊断
– 升级
– 热部署
项目经理
• 由于面向构件的软件过程提供了比传统的软件过
程明确得多的“工作产品的跟踪关系”,项目管理
可以更为有效。
• 项目经理的职责:
– 项目计划,并行开发计划
– 项目组织
– 项目实施
– 项目度量
– 突发事件处理
面向构件软件过程总览
• 如上所述,面向构件的软件过程涉及到角色、活
动、工作产品等概念。
面向对象技术弱点
• 在中小规模的软件中,对象和对象之间的协作关
系就能够满足需要。
• 但是当软件规模扩大,复杂度上升的时候,面向
对象技术强调的协作却表现出另一个极端的特点
-耦合度太高导致的复杂度。
• 这时候就需要有一种新的方法来弥补面向对象技
术的弱点。
大规模软件的特点
• 大规模软件主要特点是复杂度。比较典型
的例子是集成性的项目。
–软件系统需要将各种各样的硬件、遗留系统、
外部接口整合起来。
–其间可能遇到不同的硬件接口,不同的操作系
统,不同的语言,不同的平台,不同的数据
库,不同的消息中间件,不同的网络介质。
–这些都使得系统变得非常的复杂。
职责分工和高度协作
• 面向对象技术的特点是通过对象之间的职责分工
和高度协作来完成任务。这样的好处是代码量较
少,系统布局合理,重用程度高。
• 但是当对象的个数大量增加的时候,对象之间的
高度耦合的关系将会使得系统变得复杂,难以理
解。
对象组织容器-包
• 以前对于这个问题的方法是采用包作为容器来组
织对象,对象之间的依赖性将转化为包之间的依
赖性。这种方法听起来有道理,但是在实际中仍
会出现难以解决的问题。
– 包仅仅只是容器。这意味着对对象的组织可以是任意
的,而包之间依赖关系的设计则还是取决于对象的依
赖。
– 此外,包的设计和对象一样,缺乏一个统一的风格。
而统一的风格正是大规模软件设计所必须的,因为这
样可以有效改进系统的可理解性,这一点非常重要。
面向组件编程
• 面向组件编程的缩写是COP。COP是对
OOP的补充,帮助实现更加优秀的软件结
构。组件的粒度可大可小,需要取决于具
体的应用。
• 在COP中有几个重要的概念:服务,服务
(Service)是一组接口,供客户端程序使
用。
–例如,验证和授权服务,任务调度服务。服务
是系统中各个部件相互调用的接口;组件,组
件(Component)实现了一组服务,此外,组
件必须符合容器订立的规范,例如,初始化,
配置、销毁。
• COP是对一种组织代码的思路,尤其是服
务和组件这两个概念。
–其中Spring框架中,就采用了COP的思路,将
系统看作一个个的组件,通过定义组件之间的
协作关系(通过服务)来完成系统的构建。
–这样做的好处是能够隔离变化,合理的划分系
统。而框架的意义就在于定义一个组织组件的
方式。
理解组件
• 组件不是一个新的概念,Java中的javaBean规范
和EJB规范都是典型的组件。组件的特点在于他
定义了一种通用的处理方式。
– 例如,JavaBean拥有内视的特性,这样就可以通过工
具来实现JavaBean的可视化。而EJB规范定义了企业
服务中的一些特性,使得EJB容器能够为符合EJB规范
的代码增添企业计算所需要的能力,例如事务、持久
化、池等。
• 组件比起对象来的进步就在于通用的规范的引入。
通用规范往往能够为组件添加新的能力(就像上
面所讨论的),但也给组件添加了限制,例如你
需要实现EJB的一些接口。以下我们将讨论组件
的一些相关问题:
– 组件的粒度
– 针对接口
组件的粒度
• 组件的粒度是和系统的架构息息相关的。组件的
粒度确定了,系统的架构也就确定了。
– 在小规模的软件中,可能组件的粒度很小,仅相当于
普通的对象,但是对于大规模的系统来说,一个组件
可能包括几十,甚至上百个对象。
– 因此,对使用COP技术的系统来说,需要正确的定义
组件的粒度。较好的定义粒度的方法是对核心流程进
行分析。
针对接口
• 接口和实现分离是COP的基础,没有接口
和实现的分离,就没有COP。接口的高度
抽象特性使得各个组件能够被独立的抽取
出来,而不影响到系统的其它部分。
接口和实现分离好处
• 在模块/组件/对象之间解耦。
• 轻松的抽换实现,而不用修改客户端。
• 用户只需要了解接口,而不需要了解实现
细节。
• 增加了重用的可能性。
Inversion of Control(IOC)
• IOC是Inversion of Control的简称。它的原
理是基于OO设计原则的好莱坞原则(The
Hollywood Principle):
–不要访问我,我们将访问你。
–也就是说,所有的组件都是被动的
(Passive),所有的组件初始化和调用都由容
器负责。
IOC实现的类型
• 基于方法参数调用的Method-based(M) IOC,它把组件传
递给每个方法调用
• 基于接口的Interface-based(I) IOC(通常称为类型1),
它使用接口来声明组件之间的依赖性,例如,
Serviceable,Configurable
• 基于Setter方法的Setter-based (S) IOC(通常称为类型
2),它使用setter方法来设置组件之间的依赖性
• 基于构造函数的Constructor-based(C) IOC(通常称为类
型3)
• IOC模式称为Dependency Injection模式。
• IOC是框架开发的一个基本原理。
• 在开源软件中,不少的容器类框架都采用
了IOC的思路。例如:
– PicoContainer(http://www.picocontainer.org/)
– Spring(http://www.springframework.org/)
组件污染
• 在IOC的第一类型中,由于组件需要实现一些特
定的接口,或是从某个类集成。这将使得组件受
到一些约束(称为Invasive),例如组件移植不
便。
• 另一种情况是组件需要依赖于一个特定的容器,
最为典型的就是EJB,组件无法脱离容器单独存
在,这也使得组件受到约束。
• 这两种情况都属于组件污染。
• 最理想的组件是只专注于自身工作的组件,它没
有其它额外的逻辑。不过按照这种
标准
excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载
,目前大
部分的代码都是不符合的。
• 因此,目前在开源软件界出现了一些轻量级的容
器框架,典型的如上文提到的PicoContainer和
spring。他们的定位就是提供一个对组件管理的
统一模式,而组件可以单独的使用,也可以放在
另一个容器中,容器仅仅只是为组件提供了一些
额外的功能,和组件本身没有直接的依赖。
• 为什么我们说接口比继承好,很重要的一
个原因就是接口更加灵活,组件的依赖性
更弱,同样的,目前另一种做法则是采用
一些标记性的语言来实现比接口更大的灵
活度。
• 例如基于xml的配置文件,以及J2SE1.5中
将要引入的属性。
组件的测试
• 组件和容器的依赖脱离为组件测试提供了一个很
好的环境。我们在测试一节中讨论过容器内测试
往往是比较麻烦的,其原因就是在于上面所说的
组件污染问题。例如在spring框架中,组件是一
个标准的JavaBean,你可以直接编写代码来设置
组件的属性和定义组件之间的依赖关系(适用于
自动化测试),也可以把这项工作交给spring容
器(适用于开发和部署)。
• 组件测试在测试的分类中属于集成测试。
理解服务
• 在讨论组件时我们谈论了组件粒度的问题。当组件的粒度
不仅仅限于单个对象的时候。在构成组件的多个对象中,
有些对象处于组件内部,不和其它的组件交互,有些对象
需要和外部组件进行交互。后一种对象起的就是服务的作
用。
• 在设计模式中,这种设计被称为Fasade模式。而在OO语
言中,他们相当于接口的概念。不管如何比喻,服务订立
了组件和组件之间的契约。这种契约是稳定的(如果业务
需求是稳定的),不会随着组件内部的变化而发生变化。
• 要理解这一点也非常的容易。对于一个提供用户认证的组
件,一个可能的服务对用户进行认证和授权,至于组件内
部采用LDAP还是关系数据库来存放用户信息,对服务来
说没有任何的差别。
• 这样做的好处有很多,一是组件之间能够以一种稳定的方
式存在,组件内部的变化不至于扩散到整个软件系统。二
是软件设计将会转向重点设计组件之间的服务,而组件的
实现细节将会隐藏起来,这不但有助于设计者更好的把握
软件的全局架构,而且有助于分工的细化。
• 服务并不是什么新颖的概念,RPC、IDL都是类
似的技术。
• 但我们谈的服务侧重架构和理念,不涉及到具体
的技术,这一点同SOA和WebService的关系类似
-SOA是一个结构性的概念,而WebService是实
现SOA的一种适合的技术。
• 服务最好实现为接口。原则上服务可以是任何一种技术:
JMS、WebService、RPC、或是简单方法调用。
• 但是出于服务的稳定性的考虑,我们不应该将一个服务和
具体的技术绑定起来,这样会使的服务发生变化的可能性
增大。
• 在Java语言中,接口是具有极大的灵活性的,因此,将接
口实现为普通的Java接口是较好的选择。不过,这样做的
话,我们也许就不能够使用远程调用,Web服务之类的功
能了,不过这并不要紧,以下就是原因。
服务适配器
• 客户端可以直接使用接口,也可以通过适当的适
配器来将普通的接口服务转换为特定技术实现的
服务。
• 个普通的接口通过适配器模式转换成和特定技术
相关的服务。在JMX技术中,也采用这种方式,
JMX平台能够将一个普通的服务端口通过适配器
进行转换,以适用于各种的
协议
离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载
,例如http、
socket、snmp等等。
AOP技术对服务的帮助
• AOP作为OO技术的补足,能够以一种优雅的方式来处理
系统的横切点。服务层面是应用AOP的绝佳位置
• 一个普通的用户注册服务通过AOP可以动态的添加各种各
样的能力。AOP提供了几个好处:
– 能够通过简单的代码为所有的服务添加功能,而不用为每个服务
编写代码,从而大大节省了代码量;
– 把横切点分离出来,这样服务仅保留了核心的代码,提高了系统
的模块化程度;
– 模块化的增加使得为服务动态的增加或删除功能成为可能,例
如,可以通过配置动态的将新的Aspect添加到用户注册服务上。
服务的测试
• 服务测试在测试的分类中属于接受测试。服务概念的引入
使得自动化的接受测试变得容易了。在大规模的软件设计
中,业务流程往往涉及到各种组件通过服务介面的相互协
作。所以这就是测试的重点。回到我们之前讨论的组件粒
度问题,如果此时你编写出的测试代码过于繁琐,说明组
件的设计粒度太小了,如果组件的粒度太大,你会发现有
些测试代码根本无法编写。
服务的管理
• 服务的管理是一个比较大的话题。一方面,在一个大规模
的系统中,虽然通过组件和服务的形式能够降低系统的复
杂度,但是服务仍然很多,需要进行管理;另一方面,服
务的状态,服务的可用性需要监控和管理,这对于大规模
应用来说是必须的。因此,服务需要一种管理形式。
• JMX规范提出的目的也是一个对各种不同的组件进行统一
管理。和我们所阐述的有类似之处。JMX分为规范和远程
接口两个部分,在J2SE1.5版本中,JMX已经纳入到J2SE
的范畴中了
软件总线(bus)
• COP仅仅只是提出了一个系统划分的基础,要构
成一个完整应用,光有组件和服务还不够,还需
要将组件和服务以一种有效的方式组织起来,有
些文章把这种组织性的代码称为Fabric,有结构
和组织的意思。而在我们的文章中,称之为软件
总线(bus)。
软件总线是什么?
• 软件总线是什么?他和计算机的总线一样,它负责在各个组件中传递
信息流,将各个组件组织起来,完成一个具体的任务。总线是一个抽
象的概念,在实际中总线也是由具体的技术构成。
– 一个总线可能是一段代码,负责调用各个组件;
– 总线也能是一个消息系统,负责收集和分派消息;
– 总线也可能是一个工作流系统,负责系统信息的流转;
– 总线还可能是一个JMX,负责将消息路由到目标组件。
• 但无论总线的实现技术是什么,总线的特点就是采用一种松耦合的方
式将组件组织起来。这样,总线本身和挂接在总线上的组件就是松耦
合的,至于组件挂接到总线的形式,也就是我们之前讨论过的服务和
服务适配器要做的事情了。
软件总线有三种可能的实现
• 目前的软件总线有三种可能的实现:
– 直接调用/远程调用/WebService,MOM,以及工作流,根据应用
系统的特点可以采用不同的总线实现。例如以调用为主的总线适
用于那些流程比较明确的应用,因为流程是硬编码的,变化起来
相对麻烦一些。
– 工作流为主的总线适用于流程比较灵活,需要复杂的分支和人为
的干预。
– MOM为主的总线则适用于大型的分布式,或是异构的应用,不同
的应用之间以一种松散的方式进行协作。
总线模型(1)
• 消息总线同时应用于层间
和外部应用
• 优点
– 模块化提高集成性
– 异构平台
• 问题
– 业务层依赖UI层的信息
– 消息总线要支持多种通讯
– 消息总线要实现满足层间和
外部应用的灵活性和可用性
总线模型(2)
• 消息总线只应用与外
部应用之间
• 优点:
– 系统效率
– 设计和实现简单
• 问题:
– 降低了系统的扩展能力
服务和总线规范才是软件组织的
核心竞争力
• 但是无论采取哪一种的总线实现方式,组件和服务是不变
的,变化的是服务适配器,MOM的服务适配器和工组流
的服务适配器是不同的。
– MOM的服务适配器主要的工作是将消息中的内容翻译为POJO,
并调用服务;
– 而工作流的服务适配器可能就只是一个基于当前工作流状态的调
用。
• 这样形成的系统架构就是相对稳定、松散耦合的,不论是
组件发生变化,还是总线的技术发生变化,只要服务和总
线的规范是稳定的,整体的软件系统就是稳定的。
• 而服务和总线规范才是软件组织的核心竞争力所在,而这
也正是软件总线的主要目的。