张纯 张敬周
(上海计算机软件技术开发中心,上海 201112)
1引言
软件架构在大规模软件开发过程中扮演着越来越重要的角色,架构研究已经成为软件开发和产品线研究中的一门重要学科。在开发过程中,软件架构提供系统的高层抽象、支持开发人员之间的交流、支持软件复用
[1],因此软件架构设计在软件生命周期中起关键作用。
多年来,软件架构主要被认为是一组构件、连接器及其交互关系的高层抽象
[1]。许多架构描述框架只关注软件架构本身。例如Kruchten提出的“4+1”视图
[2]和IEEE-1471
[3]都侧重对软件架构本身的记录和编档。但是这类架构描述方法存在如下一些问题
[4]:
(1)难以描述架构在系统演化过程中的变化;
(2)无法表示架构设计的基本原理和候选设计;
(3)缺乏多方面追溯能力,如从需求追溯到相应
的架构元素。
这些问题大部分都归因于在架构设计过程中未显式的记录和编档架构设计决策
[4]。架构设计是一个不断制定设计决策的过程,如未及时记录和编档架构设计决策及其基本原理等相关知识,这些知识会逐渐丢失,从而无法在需要时重现导致最终架构的决策过程以帮助理解,更无法被复用以解决相似问题。
因此,近年来软件架构方面的研究越来越重视导致最终架构设计结果的设计决策及其基本原理。Tyree和Akerme提出把架构设计过程中的设计决策作为一级实体(first-class entity)进行显式化的记录和编档
[4]。Jansen和Bosch颠覆了人们对软件架构的传统理解,提出软件架构是一组架构设计决策的结果
[5],强调架构设计决策在设计软件架构,特别是在满足系统的质量属性方面具有重要作用。在2006年度的架构知识共享与复用研讨会上,与会专家一致认为,需利用工具记录和管理架构设计决策,并把它作为架构编档的一部分
[6]。
首先,本文分析了架构设计决策制定过程,提出描述设计决策与其它外部元素之间关系的元模型,并分析了架构设计决策的属性;以此为基础,进而给出结合“编码化”和“人际化”管理策略的架构设计决策管理工具的具体设计。本文的研究旨在为开发架构设计决策管理工具建立理论模型基础,并提供参考设计。
2 架构设计决策模型
架构设计决策是为满足系统需求所考虑到的一组候选以及最终选择的设计决策。在设计时,架构师通常根据个人的专业技能和经验知识制定合适的设计决策来解决架构问题。但是,与制定决策相关的知识如决策的基本原理以及制定决策时考虑到的候选设计决策等知识大部分都留在设计师脑中,并没有被编档和管理。为了对其进行编档和管理,首先需要分析架构决策制定过程中设计决策与其它外部元素之间的关系,然后需要分析并定义其描述属性。
2.1 软件架构设计决策元模型
架构设计决策制定过程中的主体是
涉众(包括架构师、客户、项目经理等),涉众对系统有不同的
关注点(包括功能需求和非功能需求),这些关注点可细化为不同的
场景。在分析理解场景后,架构师会提出一组
候选设计决策来解决相应的架构问题。需要分析比较这些候选的优缺点,进行权衡分析并确定一个候选设计决策递交评审,通过评审才能成为最终的
架构设计决策。架构设计决策将指导设计人员完成相应的
架构解决方案,成为
系统架构的一部分。
基于上述分析,提出一个架构设计决策的元模型(如图1所示),用于表示架构设计决策、架构解决方案、涉众以及需求之间的关系,它是设计与实现架构设计决策管理工具的基础。
图
1
架构设计决策元模型
2.2 软件架构设计决策描述属性
在架构设计决策元模型基础上,还需要识别和定义设计决策的描述属性,才能进行结构化的存储和管理。
首先,设计决策针对具体的架构问题。因此,需要
决策主题属性简要描述所要解决的问题。针对一个决策主题会考虑多个
候选设计决策,为了帮助理解、评审和复用,需要记录
决策内容、导致该决策的
基本原理(为何采用该设计,如每个候选设计决策的优缺点分析甚至复杂的权衡分析等)、
前提假设(如制定决策所依据的成本、进度等假设)、
适用范围、
约束(描述采用该决策可能对环境产生的约束)和
影响(设计决策可能会导致新的需求或者修改现有的需求,或需要引入新的设计决策)。
设计决策是一个渐进的过程,候选设计决策从被提出到最终采纳要经历一系列的
状态变化过程:首先,提出的候选设计决策处于
待定初始状态,架构师在分析后决定采用某设计,所
决定的设计在经过架构评审委员会的评审后,可能被
批准或
否决。被批准采用的设计决策也可能
失效,如新需求导致采用新的架构设计决策,使原先的设计决策无效。图2描述了一个可能的状态变迁关系。用户可根据项目需要定制。
图
2
架构设计决策的状态变迁
系统的设计决策之间还存在一定的关系:如在上面的状态变化描述中,新的设计决策可能会导致以前的设计决策失效,称之为新的设计决策
排斥旧设计决策;如果取消决策B后也必须取消决策A就称决策A
依赖决策B;如果决策B是决策A的一个子集,则称决策A
包容决策B;此外,还有上面所提到的
候选关系。表1列出上述几种常见关系,也可以自定义其它关系。
表
1
架构决策之间的关系
|
决策关系
|
自反性
|
传递性
|
对称性
|
|
依赖
|
是
|
是
|
-
|
|
排斥
|
-
|
是
|
是
|
|
包容
|
是
|
是
|
-
|
|
候选
|
是
|
是
|
是
|
记录和维护关系有助于维护架构设计的一致性。因此,需要记录每个设计决策的
相关设计决策。
为解决架构设计过程中的追溯问题,不仅需要记录设计决策对应的
相关场景,实现从设计决策到系统需求的向上游追溯;还要记录由设计决策指导形成的架构解决方案(体现为
相关制品,如设计决策所影响的架构视图、设计文档等),实现从设计决策到架构解决方案的向下游追溯。由此,架构设计决策弥合了需求与架构之间的隔阂。
此外,
修改历史属性用于文档跟踪和流程审核,
复用历史属性用于统计分析以便从中提炼通用架构设计模式。
第3节将以上述架构设计决策元模型及描述属性为基础,给出架构设计决策管理工具的参考设计。
3 架构设计决策管理工具的设计
本文提出了一个基于Web的三层架构管理工具的设计(如图3所示),支持“编码化”和“人际化”方式的设计决策记录、管理和共享复用。它简单易用、扩展性强,较为适合地域分散的软件项目组织。
架构设计决策可分为组织级和面向特定应用两类。组织级的架构设计决策通用性强,可以在不同项目中复用。为便于管理,把通用设计决策和面向特定应用的设计决策分别存储。
如图3所示,该工具主要有如下功能模块:
1) 设计决策管理
决策管理包括添加设计决策和维护设计决策。用户可按设计决策描述属性表单添加设计决策,也可使用向导方式导入设计决策。设计决策维护包括修改、删除和一致性检查等功能。
一致性检查在如下几种情况下发生:
l 添加设计决策:当添加(或导入)新的设
计决策时,依据它与相关设计决策之间的关系,检查是否存在冲突。例如:如果新添加的决策排斥一个现有决策,则存在冲突,在此情况下要提醒用户。
l 修改设计决策:这存在两种情况。第一种
情况是当相关设计决策/相互关系发生改变时;第二种情况是当设计决策的状态发生变化时(如状态从
批转变为
失效时,检查是否有其它决策依赖它)。
l 删除设计决策时,也要检查是否有其它设
计决策依赖它。
2) 设计决策检索
支持三种检索方式:对单个属性按关键字检索、对多个属性按关键字构造复合检索、全文检索。
在浏览检索结果后,用户可以直接复用候选设计或者修改候选设计决策以满足当前上下文的需求。修改后的候选设计决策就是一个新的候选设计决策,但是为了追溯性,把它和原来的候选设计相关联。
即使没有检索到可直接复用的设计决策,用户仍可从相关的设计决策中获得启发,创建新的设计决策来解决问题。
3) 设计决策展示
根据描述属性,基于Web方式可视化展示设计决策。如果设计决策属性值是外部文档,则显示为链接。对于相关设计决策,则以表格形式列出每个相关决策的链接及其关系。另外,对于多层嵌套设计决策,提供缩放机制,方便用户在各层之间浏览。
对于用户选定的设计决策,可以按关联树的形式显示相关场景(名称以及链接),实现以设计决策为中心的向上游追溯。对于以设计决策为中心的向下游追溯,则通过对相关制品属性链接的访问实现。
设计决策评审主要包括评审流程管理和评审组织管理。评委在收到候选设计决策评审请求后可直接在Web界面上浏览并完成评审。而送审人可及时通过邮件通知了解评审结果。管理员可通过评审流程管理模块定制评审流程,如:评审步骤,每个步骤系统应激发的动作等。而通过评审组织管理模块可定制评委会的人员组成及角色。系统基于群件的工作流引擎和电子邮件支持,结合评审流程和评审组织,可实现评审流程的自动化。
5) 在线交流
主题讨论区不仅可让用户在架构构建过程中进行有效协作,交流和分享经验;还可以存档那些在制定决策时本应该显性化表示但因遗忘或个人习惯而未记录的信息。另外,用户可以通过即时通信功能随时与在线用户交流,进行更有效的协作。
这些都是“人际化”的管理策略,目的是通过用户之间的互动使知识得以显性化和共享。通过合适的知识挖掘工具,还可促进知识从“人际化”向“编码化”管理转化,提高知识的使用和复用效率。
6) 专家网络
这是对在线交流功能的补充。一方面,用户可以通过博客对外发布自己的专业经验、或新的想法等;另一方面,用户也可以在通过专家黄页了解相关领域的专家信息后有的放矢的寻求帮助。
7) 系统管理
这包括用户管理和群件配置管理两个子功能。用户管理模块根据用户数据库中存储的安全信息完成登录验证,并根据数据库中存储的角色和权限的映射关系完成访问授权。
在架构设计过程中,多个涉众需交互协作才能制定高质量的架构设计决策。群件支持对于地理上分散的项目组织更是必不可少的。群件的主要功能包括:电子邮件、任务、即时通信机制等。群件配置管理模块用于全局的群件运行参数配置。
4 结束语
分析了架构设计决策的重要性,提出一种表示架构设计决策与外部元素关系的元模型,描述了架构设计决策的属性,并以此为基础设计了一个管理工具,实现了对设计决策的显式编档、管理和复用。
在下一步工作中,我们将实现该工具,研究如何在敏捷开发过程中使用该工具管理和复用设计决策,以及利用该工具进行有效的软件架构评审。