作者:
张晓春
关键词:
需求工程； 场景； 需求捕获； 需求分析； 有限自动机； 消息序列图(MSC)； 标号迁移系统(LTS)
摘要:
随着软件工程学科的发展,需求工程日益得到人们的重视。需求分析作为软件生命周期极为重要的一个环节,关系到软件工程项目的成功与否,并且在很大程度上决定了软件产品的质量。因此,如何有效地捕获用户的真正需求已经成为软件工程学科研究的重点。场景被认为是引出、文档化和验证需求的较为有效的工具,其支持非形式化、叙述性和具体化的描述,关注用户与软件环境交互的动态特性,因而参与需求分析过程的实践者和用户都能很容易地使用场景来表达其对需求的理解,以达到最佳的交互状态,从而更好地获取用户需求。这样,通过让用户真正地参与到需求分析的过程中,可以更好地将应用领域问题映射到计算机领域,并且在需求获取的迭代过程中可以自动地适应系统需求的不断变化,避免了由于需求变更而导致的系统体系结构的改变,同时也能及时添加新的需求或修改已有的不符合用户实际需要的场景,有利于保证应用软件开发的正确性及完整性。由于在开始阶段得到的是对场景的非形式化描述,而作为工程目标的软件系统是由程序及其运行环境组成,二者不仅从内容到形式都存在巨大的差别。为此,需要在它们之间建立起映射,使得程序能够正确建模用户的需求。传统的结构化方法将软件系统视为数据加工的过程,其利用功能分解的办法将系统分为不同的功能模块,每个模块进行一个子加工。虽然结构化方法曾经是软件工程实践中的主流技术,并且至今仍具有重要的影响,但是随着现代软件系统日趋复杂,各组件之间具有的各种动态交互关系以及需求的不断演化,使结构化方法愈发难以胜任。因此,如何归纳出系统的功能以及各个组件和外部参与者之间的交互就成为工程实践的中心任务。如果能够据此合成出系统的状态模型并生成代码框架,将有助于提高软件质量及降低成本。对于传统的分析方法来说,需要运用非形式化的手段,发挥创造型思维来分析用户的需求。在这个过程中,对于不同用户和分析人员,由于各自不同的工作领域和思维模式,他们之间存在着交流上的障碍,造成得到的需求难以正确和完整。如何与用户交流以得到其真正需求也成为一个重要环节。根据以上构思,首先由用户提交目标系统的初始期望场景集和例外场景集;然后生成全局系统的状态图,在此过程中不断检验出隐含的期望场景和例外场景,并辅助状态图的合成,最终完成从用户提交的场景描述到利用形式化方法建立需求模型的过程。在这个过程中介绍了目前流行的形式化建模方法的基本概念,并着重描述了本篇实例中所用到自动机理论及相关技术。为了研究从场景需求规约得到系统功能规约的步骤,本篇将通过建模一个手机短信服务系统宋阐述基于MSC(Message Sequence Chart)-场景的需求引出过程。为了得到形式化的功能规约,需要由用户输入的场景合成出前缀树识别器(Prefix Tree Acceptor),即根据对场景的描述画出MSC,遍历MSC的消息得到若干个事件序列的集合,然后将多个事件序列在具有共同前缀的地方连接起来。由于前缀树识别器是直接根据用户场景的事件序列转换而来的,没有很好地揭示若干事件和状态之间的本质联系,并且包含大量的冗余状态,所以需要对这些状态进行合并。合并状态后的系统可能接受更多的事件序列,然后将这些新产生的序列提交给用户判断:目标系统中能否出现这样的事件序列,并根据得到的回答来辅助合并的过程。这个过程类似一个具有负反馈能力的抽象机器,它的控制部件是合并状态的算法,反馈部件是最终用户,系统输入是初始场景集,系统输出是完成状态合并的自动机模型,反馈输入是合并后新接收的事件序列,反馈输出的是最终用户对这个事件序列所作的判断。如果系统合并过多(或过少)的状态,通过反馈就会抑制这个过多(或过少)的合并,使得生成的自动机平稳、渐进地趋向于目标系统。由此就可以把用户场景的形式化过程映射为系统模型的归纳过程。根据合并好的自动机模型,依照映射规则就可以按部就班地编写组件的代码框架。最后利用面向对象的软件设计方法,将每个系统组件封装为一个进程并填充具体代码,从而完成从最初场景到最终代码的整个流程。
在线下载