＋设为首页 ＋添加到收藏夹
统一用例方法 版本 a0 it之源 张恂
一.用例基础 1.1用例简史 用例技术大体上经历了萌芽.成熟与发展3个阶段[12],最早可追溯到上世纪60年代末uml（统一建模语言）.rup（rational统一过程）之父ivar jacobson（伊瓦·亚克申）博士在著名的瑞典爱立信公司领导程控电话交换机开发时采用的traffic case（话务案例）,1986年前后亚克申博士在oopsla大会上发表的论文[4]标志着用例的正式诞生.1992年,亚克申博士在其名著«面向对象软件工程:用例驱动方法»[3]中正式推出了当时已相当完善的用例方法,用例驱动成为了objectory过程（rup前身之一）的核心内容,从此用例在国外软件工程界得以迅速普及,并于90年代中后期被rup与uml吸收为核心要素,亚克申博士在«统一软件开发过程之路»[4]与«统一软件开发过程»[5]中对此作了精彩的阐述,这些书因为成为了解其用例思想的重要著作.如今,作为必不可少的关键内容,用例技术总是被所有的当代需求工程名著所引用,而“用例”本身也几乎成为功能需求的代名词.（注:考虑到历史上的渊源关系,为了方便起见,以下我们用术语“亚克申方法”或“亚克申用例”来统称rup.uml及其支持者所采用的用例方法,尽管它们彼此之间可能存在细微的差别,而且也不一定全部是由亚克申博士本人所提出或赞成的.） 用例另一支主流派别代表人物alistair cockburn（阿里斯代·寇本）上世纪90代初从亚克申那里学习了用例,随后通过十年认真广泛的实践对其进行了继承与发展.寇本于1995至1997年间提出了著名的“基于目标的用例”方法[2],他的方法与思想集中体现在«writing effective use cases»（以下简称为weuc）[1]中,以结构化/半结构化文本用例为中心是寇本方法的一大特色,该书可以说是迄今为止最为详细的一本用例教材,对于指导实践者如何写好文本用例具有很高的价值. 1.2用例定义 下面,先让我们从什么是用例开始讨论.亚克申定义[7]强调用例是系统执行的一个动作序列（注:这其中也包括与用户的交互）,这些动作必须对某个特定的使用者（actor）产生可观测的.有价值的结果.（注:actor实质上是用户所扮演的一种角色） 那么到底什么结果叫“可观测.有价值”呢?虽然两种用例本质上是一致的,但亚克申定义对此没有明说,而寇本定义[1]则更加完善与明确.它首先强调用例是各种系统受益人（stakeholder,又译“干系人”）之间的一种行为契约（注:行为包括对象的活动.动作与对象之间的交互等）,建立契约的目的是为了达成某种目标,因此每一个用例及其名称实际上都应代表一个用户目标,这个目标是否得到真正满足正是判断我们抽取的某个用例是否“有价值”的关键.寇本还点出了要通过用例的具体执行来展现actor的目标是如何实现或失败的,而一个用例其实就是多个在不同条件下执行并可能导致许多不同后续状态的情节（scenario,又译“场景”）的叠加,这就是用例结果的“可观测”. 因此综合起来,我们只要抓住这样几个关键词:目标.行为契约.行为(事件)序列（动作与交互）.情节.可观测.有价值,就可以比较准确地描述出用例的本质特征. 1.3用例的重要性 为什么用例如此重要?一言以蔽之,这是因为用例是一种普遍存在的客观现实,而实践证明,用例技术是迄今为止最为深刻.准确与有效的系统功能需求描述方法. 功能需求是指系统输入到输出的映射以及它们的不同组合[9],任何功能必然要通过外部环境与系统之间的交互才能完成,这不正是用例所要反映的内容吗?因此,我们可以在内容与形式上把用例与系统的功能需求等同起来,并且得出推论:只要是软件,必然都存在用例（虽然有时候不一定非要用某种具体的用例格式来描述）,其中即包含数据流,也包含控制流,既包含消息发送与数据交换（交互）,也包括活动/动作的执行以及状态的变迁.这些就是用例的本质（现象背后那个真实的.抽象的“胚”）,而各种格式文本.uml图形（我们至少可以用4种uml动态图来描述用例）不过是用例的外部表现形式.所以,与其说亚克申博士发明了用例,还不如说亚克申博士早在20年前就发现了用例这种客观现实,并最终发明了用例表示与用例驱动软件过程的方法.... 下一页