领域需求建模规范0316.docx
- 文档编号:25779243
- 上传时间:2023-06-13
- 格式:DOCX
- 页数:15
- 大小:158.79KB
领域需求建模规范0316.docx
《领域需求建模规范0316.docx》由会员分享,可在线阅读,更多相关《领域需求建模规范0316.docx(15页珍藏版)》请在冰豆网上搜索。
领域需求建模规范0316
领域需求建模规范
1.概述
1.1编写目的
用于指导领域建模人员进行领域需求建模。
1.2适用部门
适用于面向领域的嵌入式开发环境项目组。
1.3规范执行日期
自本规范审核通过之日起执行。
1.4规范执行制度
进行领域需求建模时,要求建模人员一律严格按照本规范的流程进行建立。
2.领域需求建模流程
领域需求建模的流程如下所示:
1)由领域专家提供关于领域中系统需求规约和实现的知识,组织出规范的、一致的领域术语,记录在领域词典中。
2)根据领域词典,用自然语言对领域需求进行描述。
3)领域分析人员可以把一个领域中各应用系统所描述的服务、以及采用的各种技术抽象成为特征,建立特征模型。
4)通过对领域知识和现有的应用系统的分析,挖掘领域中所存在的各种用例,建立用例模型。
2)和3)是同时进行的,同时在此过程中完善领域词典。
5)构造出用例与特征的对应表。
领域需求模型建立流程图如图2.1所示:
图2.1领域需求建模流程图
2.1建立领域词典
建立领域词典的目的是统一术语。
统一术语可以使领域工程的参与者有共同的语言,便于领域工程的实施。
术语也就是对事物的分类。
统一术语的过程,也就识别了领域中有哪些共同事物,以及这些共同的事物可以有何种共同的分类方式,即识别了领域中的共同性。
随着领域需求模型的生成,领域词典也将随之更新演化。
领域词典中包括了名词(词组)、动词以及特征名称。
在领域需求模型建立过程中,所用到的事件、对象、角色等都要与领域词典中的条目保持一致。
2.1.1名词(词组)
任何能够指代领域中实体或抽象事物的名词或者名词词组。
例如:
住宅安全系统。
2.1.2动词
形容和表示各类动作的词汇。
例如:
控制。
动词需进行分级,分为1级、2级、3级等等,数字越小,级别越高。
例如:
精通(1级),掌握(2级),了解(3级)。
2.1.3特征名称
每个特征都必须有自己唯一的名称,并且在领域词典中有相应的定义:
●对于功能性特征
采用名词(或名词词组)+动词的命名规则,名词和动词在领域词典中应该包含对它的定义。
例如:
磁卡访问。
●对于非功能性特征
采用名词(或名词词组)的命名规则,例如:
安全性。
●对于硬件特征
直接用硬件名作为特征名称。
例如摄像头。
2.2描述领域需求
采用自然语言对需求进行描述。
所描述的需求应具有以下特点:
●完整性
每一项需求都必须将所要实现的功能描述清楚,使开发人员获得设计和实现这些功能所需的全部必要信息。
●正确性
每一项需求都必须准确地描述其开发的功能。
●可行性
每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
●必要性
每一项需求都应该是客户真正所需要的和最终系统所遵从的标准记录。
●无二义性
对所有的需求说明都只有一个明确的统一的解释。
●可验证性
检查一下每项需求是否能通过设计测试用例或其它的验证方法。
领域需求一般用以下句型描述:
描述完一条需求要换行,每条需求的前面用符号(R+序号+:
)表示。
在以下句型中,n指代名词或名词性词组,v指代动词或动词性词组,()内为可替换的,【】内为可选的。
●当+n+v【+n】+时(前)(后),n+v【+n】。
例子:
当用户按下启动按钮时,系统运行。
●n+能够+v+n。
例子:
系统能够提供用户注册功能。
●n+可以是+n【+、(或者)+n】。
“、”表示多选多。
“或者”表示多选一。
例子:
用户名中的字符可以是英文字母、数字。
●n+要求(允许)+n+达到(至少)(为)+n
例子:
系统要求处理器频率至少2.0GHz。
2.3建立特征模型
特征是系统中用户可见的、显著的或具有特色的方面、品质、特点等。
特征的识别主要是通过对已有的领域知识进行抽象来完成的,领域知识则来源于领域专家,书籍,用户手册,设计文档和源代码等各种信息源。
特征可以是应用系统提供的服务,应用系统的性能,应用系统需要的硬件平台、费用及其他相关信息等。
特征模型是对一个特定领域的软件所具有的特征的有组织的描述,主要记录了特征自身具有的重要属性和特征之间存在的各种关系。
特征模型主要包括:
●通过组成关系形成的特征层次分解图,即特征树;
●每个特征的变化性类型和绑定时间属性;
●每个特征的具体描述;
●特征之间存在的约束关系。
2.3.1特征树
特征模型主要由特征树组成,特征在特征模型中的表示方法如表2.1所示:
表2.1特征图例表
分类
图例
功能特征
非功能特征
硬件特征
特征树通过以下关系组成:
●包含关系(include)
包含关系是特征之间的主要关系。
一个父特征可以包含一系列的子特征。
通过包含关系,特征以一种树状的层次结构被组织在一起。
在特征模型中,用实线连接父特征和子特征。
特征A包含了特征B、C、D的图例如下所示:
●特殊化关系(specialization)
一个泛化的特征在具体的环境中根据不同的情况被扩展为一组具有不同细节的特征。
在特征模型中,特征A特殊化为特征B、C、D的图例如下所示:
2.3.2特征模型的可变性
为捕获领域中应用系统的共性和变化性,我们定义以下几种特征。
●必选特征:
指在领域中每个应用系统中都应该包含的特征。
●可选特征:
指对于领域中的各个应用系统可有可无的特征。
●多选一特征:
是对某一个一般性特征的具体化。
只能选择一个。
●多选多特征:
也是对某一个一般性特征的具体化。
可以选择多个。
在特征模型中,必须对所有可选的、多选一特征、多选多特征进行标识。
例如在图3.2中,访问控制为必选特征,用符号
表示。
室内监视为可选特征,用
符号表示。
室外运动检测和室外视频检测室多选一特征,用
符号表示。
磁卡访问和密码访问为多选多特征,用
表示。
对可选特征的选择或者多选一特征、多选多特征的选择,可以由软件体系结构设计人员来决定它们的绑定时间。
绑定时间就是指特征在整个生命周期中必须被做出绑定或删除决策的时间段。
有三种类型的绑定时间:
编译时、装载时、运行时。
2.3.3特征之间约束关系
特征之间主要包含以下几种约束关系:
●使用关系(use)
使用关系描述功能性特征之间的调用关系。
表示使用特征调用被使用特征完成之后的结果。
对于两个特征A和B,特征A使用特征B的图例如下所示:
箭头指向被使用特征。
●通知关系(inform)
对于两个特征A和B,AinformsB表示A向B发送特定的信息以通知B特征的事件已经发生。
特征A通知特征B的图例如下所示:
箭头指向被使用特征。
●需要关系(require)
需要关系是指由于语义或逻辑上的关系,一个特征的存在要求若干个特定特征的存在。
对于两个特征A和B,特征A需要特征B的图例如下所示:
箭头指向被依赖特征。
●互斥关系(exclude)
互斥关系是指两个特征之间由于语义或逻辑上的矛盾关系而不能同时存在于某个环境中。
特征A与特征B互斥的图例如下所示。
2.3.4特征描述
特征描述采用文本的方式对特征分解视图进行描述,特征描述中的关键字主要是用于表述特征之间的关系,如表格2.2所示。
所有的特征通过英文符号的逗号“,”隔开;特征列表用英文符号的括号“()”括起来;特征与其后面的特征列表用英文字符的冒号“:
”隔开;每一个功能的描述占据一行。
具体语法如下:
future:
relation-keyword(sub-future,sub-future,……)
表2.2特征描述关键字
关键字
含义
all
表示该特征由后面的所有特征组成
more-of
表示该特征由一个或多个后面的特征组成
one-of
表示该特征由其中一个后面的特征组成
specializations
表示该特征特殊化为后面的特征
?
表示该特征可有可无
use
表示该特征依赖后面的特征,依赖关系为use。
inform
表示该特征依赖后面的特征,依赖关系为inform。
requires
表示该特征依赖于后面的特征,依赖关系为inform。
excludes
表示该实体与后面的实体不能共存,存在排斥关系
2.3.5特征模型举例
图2.2是住宅安全系统的部分特征图。
图2.2住宅安全系统部分特征图
其中每个特征的详细描述如表2.3所示:
表2.3住宅安全控制相关特征的描述
特征名称
特征描述
住宅安全控制
是对整个住宅安全进行控制,进一步包含室内检测、访问控制、入侵检测等子特征。
室内监视
利用摄像头对室内的环境进行监视。
包含一对多选一的特征:
视频监视、室内运动监视。
访问控制
对进入住宅的访问者进行识别。
包含一对多选多的特征:
磁卡访问、密码访问。
入侵监视
对采用其他方式进入住宅的访问者进行监视。
包含破窗检测和一对多选一的特征:
室外视频监视、室外运动监视。
室内视频监视
对室内进行监视,有异常发出警报。
室内运动检测
对室内运动物体进行检测。
磁卡访问
访问者使用磁卡进行访问。
密码访问
访问者使用密码进行访问。
破窗检测
对窗户完好度进行检测。
室外运动检测
对室外的运动物体进行检测。
室外视频检测
对室外进行视频监视。
摄像头
在进行室内视频监视和室外视频监视时需要用到的摄像头硬件。
安全性
是住宅安全系统的安全性。
反应时间
是住宅安全系统对异常出现作出相应动作的反应时间。
特征文本描述如下所示:
住宅安全控制:
all(访问控制,入侵检测,室内监视?
)
访问控制:
more-of(磁卡访问,密码访问)
入侵检测:
all(破窗访问,one-of(室内运动检测,室外视频检测))
室内监视:
one-of(室内视频监视,室内运动检测)
室内视频监视:
requires(摄像头)
室外视频监视:
requires(摄像头)
2.4建立用例模型
用例模型主要是通过对领域知识和现有的应用系统的分析,挖掘领域中所存在的各种用例。
用例模型包括用例图、用例场景(时序图)和用例描述。
这里采用UML相关规范构建用例模型。
2.4.1用例图
用例图主要用来图示化系统的主事件流程,它主要用来描述客户的需求,即用户希望系统具备的完成一定功能的动作。
它以图形的方式定义系统的各功能点和参与者以及其之间的相互关系。
用例图中的图例如表2.4所示:
表2.4用例图图例
名称
图例
备注
参与者
用例
用户参与用例
用例扩展
第一个用例给第二个用例增加步骤,就称为扩展第二个用例,例如查看单据明细是查看单据表头的扩展。
用例泛化
父用例可以特化形成一个或多个子用例。
用例包含
第一个用例包括第二格用例的全部步骤,就称第一个用例包含第二个用例,主要用于用例分解。
用例图示例如图2.2所示:
图2.2用例图示例
2.4.2用例场景
用例场景描述了两个或多个角色之间的交互序列。
描述场景的方法是使用序列图。
序列图的功能是针对每个用例,描述各个对象如何相互协作完成整个业务活动,下面定义序列图的绘制格式。
序列图中图例如表2.5所示:
表2.5序列图图例
名称
图例
备注
对象及其生命线
对象之间调用关系
箭头指向被调用的对象
对象调用自身操作
调用方和被调用方对象都是相同的
返回调用结果(消息)
返回对象操作的结果
参与角色
序列图示例如图2.3所示:
图2.3序列图示例
2.4.3用例描述
文本格式的用例描述通常采用用例模板实现结构化。
要求指明用例名称、用例描述、参与者、前置条件、后置条件、基本操作流程。
表2.6是用例描述的例子。
表2.6运动物体检测用例描述
用例名称
运动物体检测
参与者
户主
标识符
UC001
用例描述
……
前置条件
住宅安全系统运行中
后置条件
基本操作流程
户主设置安全系统
户主开启/关闭报警
可选操作流程
无
2.5用例特征对应表
通过序列图中的事物对象将用例和特征对应起来,形成用例特征对应表。
用例特征对应表结构如下表所示:
将用例名称写入左边一列,将该用例对应的特征写入右边一列中。
如表2.7所示。
表2.7用例特征对应表
用例名称
事物
特征名称
用例1
事物1
特征1
特征2
事物2
特征3
……
用例2
事物3
特征4
特征5
……
……
……
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 领域 需求 建模 规范 0316