UML软件工程组织

软件开发新思维
作者:胡健 选自:敏捷中国
软件开发长期以来被认为是一项富有创造性的活动。一个软件开发机构在接到一个新的项目之后,通常遵循需求、获取、分析、设计、实现、集成和测试的步骤,进行项目的开发。传统的开发方法并不强调软件复用,这样就必然导致大量的重复劳动,给软件企业造成巨大的人力、物力和财力的浪费。对比一些成熟的工程领域,复用是这些领域的一个基本特征,例如土木工程、化学工程、计算机硬件工程等。通过大量复用经过实践检验的系统体系结构和标准化的构件,使得对于一般的设计问题都可以直接利用现成的解决方法,避免了系统开发时“不断重复地发明车轮”,从而大幅度降低开发成本、提高生产效率和产品质量。系统化的复用将为软件企业在竞争日益激烈的市场上赢得有利的地位,因此,对软件复用的研究和实践越来越引起学术界和产业界的高度重视。

----在国家“九五”重点攻关项目青鸟工程中,对基于复用的软件生产技术进行了深入的研究和实践,实现了基于构件-构架的软件生产线系统,制定了系列标准和规范,为软件的工业化生产和工程化开发提供了必要的基础和能力,并取得了初步的成果。

----在青鸟软件生产线系统的基础上,我们与浪潮集团通用软件公司进行技术合作,实施了“青鸟软件工业化生产技术示范工程——基于青鸟软件生产线的浪潮软件产品开发平台”,旨在提高浪潮通软的软件生产能力和市场竞争能力,同时在实践中补充和完善青鸟软件生产线系统。双方将在商业、财务、金融、工业产供销、医药等领域进行合作,目前正在实施商业领域软件开发平台的建设,满足商业零售、批发、连锁等不同业态的需求。

青鸟软件生产线
----青鸟工程在“七五”期间提出了软件生产线的思想, “八五”期间对软件生产线的思想进行了实践和丰富,“九五”期间对基于构件-构架模式的软件工业化生产技术进行了研究,并实现了青鸟软件生产线系统。青鸟软件生产线同时支持面向复用的开发和基于复用的开发,为软件复用提供了一个比较全面的解决方案。

----如图1所示,青鸟软件生产线将软件的生产过程划分为三类不同生产车间的活动,即应用构架提取车间、构件生产车间和基于构件-构架复用的应用集成(组装)车间,在这三个车间之间存在着两个库,即应用构架库和构件库,从而形成软件生产组织内部的合理分工,构划出了软件生产过程,奠定了软件工程化开发和工业化生产的基础。通过标准规范和质量保证对整个生产过程提供支持。

----青鸟软件生产线中的主要活动如下:

----(1) 应用构架提取车间,从一组现有的软件系统中提取可复用的构架,并存入到构架库中。

----(2) 构件生产车间,以应用构架为指导生产可复用的构件,这些构件可以是专为复用而开发的,也可以是从现有系统中提取、修改、包装而得到的,生产出的构件存入构件库中。

----(3) 应用组装车间,根据当前应用系统的用户需求,从构架库中选取合适的可复用构架或设计新的构架,并以此为指导,从构件库中得到合适的构件,进行必要的适应性修改,可能还要开发一些新的构件,进行组装,得到新的应用系统。

----(4) 产生新的应用系统后,“现有系统”的集合扩大了,这时要根据新的“现有系统”对可复用构架进行演化,可能还会有新的构件入库。

----与这些活动相对应,在青鸟软件生产线中,软件开发人员被划分成三类:构件/构架生产者、构件/构架库管理者和构件/构架复用者。这三种角色所需完成的任务是不同的,构件/构架生产者负责构件/构架的生产和维护;构件/构架库管理者负责构件分类以及构件库的管理工作;而构件/构架复用者负责进行基于构件的软件开发,包括构件查询、构件理解、适应性修改、构件组装以及系统演化。

领域工程和应用工程
----实际上,在青鸟软件生产线中的前两个车间,即应用构架提取车间和构件生产车间对应领域工程,而组装车间对应应用工程。目前对什么是领域工程还没有一个统一的定义,一般认为,领域工程是为一组相似或相近系统的应用工程建立基本能力和必备基础的过程,它覆盖了建立可复用的软件构件和构架的所有活动。这里的“领域”是指一组具有相似或相近软件需求的应用系统所覆盖的功能区域。

----图2给出了实施领域工程的基本过程,其中最重要的结果是形成面向领域的可复用构件和构架库,体现了上述领域工程定义中的“建立基本能力和必备基础”。如图2中央的环所示,实施领域工程的整个过程是迭代的,双向的箭头表示并不存在一种从输入到输出之间的单向因果关系,输入和输出实际上是相互影响和相互作用的。例如,稍微扩充一下产品空间可能意味着接纳全新的系统类型,作为可复用构件和构架的来源;类似地,生产约束(例如强制使用CORBA)可能导致在整个领域工程范围内,需要考虑对体系结构风格和模式(例如基于消息传递的分布式对象风格)的限制。这种限制反过来又将确定哪些现有的构件和构架是可供复用或挖掘的候选者。

----按照上述定义,领域工程是为一组相似或相近系统的应用工程建立基本能力和必备基础的过程,我们将开发单个应用系统的软件工程过程称为应用工程,领域工程的最终目标是为了在开发满足特定用户需要的应用工程时,通过复用领域工程的构件和构架等结果,以达到提高开发效率和质量、降低开发和维护成本的目的。

----在图3中,应用工程的实施依赖于领域工程的输出,即产品空间、构件、构架和生产计划,以及特定产品的需求,应用工程的结果是符合上述需求的产品。领域工程和应用工程之间也没有固定的顺序关系,它们是一个迭代的过程,可以采取自顶向下的开发策略,即从一组构件和构架出发,生产符合用户需求的特定产品;也可以采取自底而上的开发策略,即从一组产品出发,提炼可复用的构件和构架。

项目实施过程
----建立商业领域软件开发平台的过程就是在实施领域工程,为商业领域应用工程的实施建立基本能力和必备基础。现在比较流行的软件开发方法是面向对象方法,但随着对软件复用认识的不断深入,基于构件的软件开发逐渐成为学术界和产业界关注的焦点。构件是对象概念的延伸和发展,通常可以认为,构件的粒度比对象的粒度更大,它们是独立的功能单元,在实现上可以是一组协作的对象集合,典型的构件如 CORBA构件、DCOM构件、JavaBeans 构件等。在由对象构成的系统中,对象具有小粒度、大数量的特点。相对而言,构件系统中的构件具有大粒度和小数量的特点。鉴于目前基于构件的开发方法还处于研究阶段,缺乏完整的方法学的支持,因此在该项目的实施过程中,我们结合了面向对象方法和基于构件的开发方法,但由于其间过渡的不平滑,因此引入了“构件关系建模”活动,基本实施过程如图4所示。

----商业领域软件开发平台实施过程中主要活动如下:

----(1) 领域建模

----模型是对现实世界的一种抽象,因此,任何一个模型都不可能事无巨细地刻画现实世界的各个方面。我们采用了ARIS模型,从过程、数据、功能和数据等四个方面对不同的商业业态进行了比较完整的刻画,标识出系统的共性和变化性。从ARIS模型可以直接转换为系统的Use Case模型。

----(2) Use Case建模

----Use Cases目前被认为是一种较好地获取软件系统需求的手段,特别是在基于构件的系统开发中。通常,一个系统有许多不同类型的用户,每种类型的用户作为系统的一类活动者(actors),通过和Use Cases的交互使用系统。一个Use Case 表示了系统向活动者提供一些有价值的结果而执行的动作序列。所有活动者Use Cases和它们之间的关联构成了系统的Use-Case模型,反映了用户同系统的交互,刻画了系统的功能和行为。

----在商业领域业务模型的基础上,将注意力集中于捕获系统为每个用户(即活动者)所提供的服务上,根据用户的实际需要确定系统的功能。所有用户不需要的功能是系统中不应包含的,而任何用户的每种需要又是系统中必须包含的,这样就在用户的真正需求和分析人员获取的需求之间建立了一一对应的关系。

----(3) 面向对象分析

----需求规约阶段的主要任务是以准确、无二义的方式刻画用户需求,使开发人员能更准确地理解在需求获取阶段得到的Use-Case模型,把Use Cases 细化为对象和对象之间的交互。这个阶段以Use-Case模型作为输入,产生的结果主要包括表达系统静态特征的类图和动态特征的顺序图。

----标识系统的类和对象是建立上述静态和动态模型的基础。通过Use Cases,识别参与实现Use Cases的对象,并把Use Cases中定义的责任分配给不同的对象类。以这种方式,可以确定系统真正需要的、并实现Use Cases的一组对象类,然后建立对象类之间的关系,包括关联、依赖和继承。

----顺序图在某种意义上是Use Cases的一种实现,Use Cases在黑盒层面上表达了用户和系统的交互,顺序图则通过参与一个Use Case的对象实例之间的交互,详细地表达了如何实现该Use Case。

----(4) 构件关系模型

----前面提到过,为了弥合面向对象分析和基于构件的设计之间过渡的不平滑,我们引入了构件关系模型。在这里,构件的接口定义了一组对外提供和要求的功能,构件在实现上对应一组协作的对象。

----构件之间的关系包括功能连接和聚集两种,功能连接表达了一个构件对外提供功能和另一个构件对外要求功能之间的匹配。值得注意的是,我们这里并没有引入泛化(generalization)关系,在面向对象中是通过继承机制体现的,可以很好地支持源代码级的复用,但也存在着一定的局限性,其中最突出的是被称为“脆弱的基类(fragile base classes)”问题。继承机制在支持复用时,子类可以直接使用父类提供的属性和服务,并根据需要做适应性修改,一旦继承树中的某个非叶节点的接口发生变化时,这种影响就会波及到以该节点为根的整个子树,有时这种波及并不是所希望的;继承机制还会带来复用的效率问题,复用一个子类会引入该子类的所有父类,如果整个继承树很大(实际情况往往是这样的,如Microsoft Visual C++的MFC库,Java中类库等),会导致巨大的开销,这也是面向对象在一些对性能要求很高的领域难以广泛使用的原因之一。在构件关系模型中,我们通过使用聚集来实现构件之间的复用。

----(5) 特定于商业领域的软件构架设计(DSSA)

----构架设计是从问题空间向软件解空间过渡的第一个活动,以构件关系模型为基础,在考虑系统实现环境(如操作系统、数据库、通信机制、中间件等)和应遵循的标准等因素的情况下,形成针对特定系统或领域的软件构架。

----构架是系统实现的蓝图,在后续开发活动中的作用包括以下两个方面:1规定了构件接口和规约,有助于构件获取(例如,定制或发现相关的构件); 2为系统集成提供框架,有助于符合规定接口的构件集成。

----在开发商业领域的软件开发平台时,考虑到运行平台、构件数量、价格、市场以及商业系统传统的运行环境等方面的因素,我们选择了Windows DNA和COM+作为系统实现环境,支持具有三层体系结构的分布式应用,如图5所示。

----(6) 构件获取

----构架定义了构件的接口和相应的规约,为构件的获取提供了依据。在基于构件的系统开发中,构件的获取通常包括几种不同的方式:

----①直接从构件库中获得符合要求的构件;

----②对构件库中的构件进行适应性修改;

----③从市场上购买现成的商业构件,即COTS构件;

----④开发新的符合要求的构件。在进行以上决策时,必须考虑不同方式获取构件的一次性成本和以后的维护成本。

----在图5中,构件被分为基础构件和业务构件,这里基础构件包括:注册表、字典、编码、公式、单据、账簿、报表、图表等,支持进销调存等业务过程中的数据加工、流动和工作流的灵活定制;业务构件包括:POS机、POS Server、信用卡接口、电子秤、盘点机、条码签、物价签、会员卡等,这些特定于商业领域的应用需求,并建立在基础构件之上;商业应用模板为不同的商业业态提供参考模型,包括功能、数据和业务流程;根据不同商业企业的具体需求,通过对商业应用模板进行实例化,定制出适合该企业的具体系统。各层次之间的关系如图6所示。

新型的商业应用系统开发和组织模式
----在上述商业领域软件开发平台的支持下,商业应用系统的开发模式和开发机构的组织模式将会发生一定的变化,如图7所示。椭圆表示开发机构的人员角色,矩形表示这类角色的人员所生产和维护的软件制品。构件构架的生产、维护人员对应到类似构件中心的部门,负责整个开发机构所需的各种可复用的构件和构架;应用模板制作、维护人员对应到各个应用产品部门,如根据不同的领域划分为商业应用产品部、财务应用产品部、金融应用产品部等;应用系统开发人员负责现场实施;运行维护由软件开发机构和最终用户共同承担,由于提供了灵活的数据加工和业务流程定制的功能,因此当用户的报表和业务流程发生变化之后,用户自己就可以方便地进行定制,无需软件开发机构跟踪维护,不仅节省了软件开发机构大量的人力、物力和财力,而且因为产品的灵活性加快了对用户需求的响应速度,从而提高了产品的市场竞争力。

结束语
----青鸟工程以及青鸟软件生产线的研究和实践,其目的是为了促进软件产业的合理分工,形成构件生产业、集成组装业和服务业。随着软件技术的发展,软件构件市场已初见端倪,标志着软件工程化开发方法,以及软件工业化生产技术正在逐渐走向成熟。
----这次示范工程是基于青鸟软件生产线系统开发领域平台的一次有益的尝试,为企业提高软件生产能力和市场竞争能力提供了技术储备,同时在实践中补充和完善了青鸟软件生产线系统,为进一步的行业推广取得了宝贵的经验

文章来源:计算世界网

 

版权所有:UML软件工程组织