领域需求建模规范0329 2.docx
- 文档编号:8157063
- 上传时间:2023-01-29
- 格式:DOCX
- 页数:19
- 大小:174.36KB
领域需求建模规范0329 2.docx
《领域需求建模规范0329 2.docx》由会员分享,可在线阅读,更多相关《领域需求建模规范0329 2.docx(19页珍藏版)》请在冰豆网上搜索。
领域需求建模规范03292
LiveSky®Research
文档编号:
DTESD-DRDT-1
Confidentiallevel
(受控)
领域需求建模规范
Version1.0
湖南力唯中天研究院
AllRightsReserved
A.文档变更历史
日期
版本
变更说明
作者
B.文档审核历史
审核日期
版本
审核意见
审核人
1.概述
1.1编写目的
本规范的编写目的是定义领域需求的描述规范以及领域特征需求提取流程,提供领域需求分析的指导方法。
本规范同时可用于本工具设计、开发、及测试的参考。
1.2适用对象
Ø进行领域需求建模的相关人员:
领域从业人员、行业专家、领域建模人员。
Ø面向领域的嵌入式开发环境项目组。
Ø本工具的开发项目组
1.3引用
1、DTESD-DCT-1领域建模工具需求说明书文档3.1章领域分析
1.4参考
1、DTESD-TRSS-1面向领域的可信嵌入式软件开发环境总体需求规格说明书
2、DTSED-DESDP-1面向领域的可信嵌入式软件开发环境软件开发过程
1.5规范执行日期
自本规范审核通过之日起执行。
1.6规范执行制度
进行领域需求建模时,要求建模人员一律严格按照本规范的流程进行建立。
2.领域需求建模流程
领域需求建模的流程如下所示:
1)由领域专家提供关于领域中系统需求规约和实现的知识,组织出规范的、一致的领域术语,记录在领域词典中。
2)领域分析人员可以把一个领域中各应用系统所描述的服务、以及采用的各种技术抽象成为特征,建立特征模型。
3)根据领域词典,结合特征模型中的功能特征,用自然语言对领域需求进行描述。
4)通过对领域知识和现有的应用系统的分析,挖掘领域中所存在的各种用例,建立用例模型。
3)和4)是同时进行的,同时在此过程中完善领域词典。
5)构造出用例与特征的对应表。
领域需求模型建立流程图如图2.1所示:
图2.1领域需求建模流程图
2.1建立领域词典
建立领域词典的目的是统一术语。
统一术语可以使领域工程的参与者有共同的语言,便于领域工程的实施。
术语也就是对事物的分类。
统一术语的过程,也就识别了领域中有哪些共同事物,以及这些共同的事物可以有何种共同的分类方式,即识别了领域中的共同性。
随着领域需求模型的生成,领域词典也将随之更新演化。
领域词典中包括了以下字库:
领域名词库,领域功能动词库,领域非功能动词库,领域功能特征词库,领域非功能特征词库、领域硬件特征词库。
每个库中都包含一个表格,包括名称、所属领域、描述、同义词、分类标识符。
其中分类标识符是名称的标识符,只能包含英文字母和“_”,可以是该名称的英文全称或缩写。
在领域需求模型建立过程中,所用到的事件、对象、角色等都要与领域词典中的条目保持一致。
2.1.1领域名词库
领域名词库中包含了任何能够指代领域中实体或抽象事物的名词或者名词词组。
例如:
住宅安全系统。
领域名词库用表格形式表示如下:
名称
所属领域
描述
同义词
分类标识符
住宅安全系统
住宅安全
用于监视住宅安全的系统。
House_Security
……
……
……
……
……
2.1.2领域功能动词库
领域功能动词库中包含形容和表示各类功能动作的词汇。
例如:
控制。
领域功能动词库用表格形式表示如下:
名称
所属领域
描述
同义词
分类标识符
控制
住宅安全
掌握住不使任意活动超出范围。
Control
……
……
……
……
……
2.1.3领域非功能动词库
领域非功能动词库中包含形容和表示各类非功能动作的词汇。
例如:
具有。
领域功能动词库用表格形式表示如下:
名称
所属领域
描述
同义词
分类标识符
具有
拥有某些非功能属性。
Have
……
……
……
……
……
2.1.4领域非功能名词库
领域非功能名词库中包含描述非功能属性的名词。
例如:
安全性。
领域非功能特征词库用表格形式表示如下:
名称
所属领域
描述
同义词
分类标识符
安全性
住宅安全
系统避免处于潜在危险或不稳定状态的能力。
Security
……
……
……
……
……
2.1.5领域功能特征词库
领域功能特征词库中包含特征模型中功能特征名称。
功能特征名称采用名词(或名词词组)+动词的命名规则,其中名词在领域名词库中有记录,动词在领域功能动词中有记录。
例如:
磁卡访问。
领域功能特征词库用表格形式表示如下:
名称
所属领域
描述
分类标识符
磁卡访问
住宅安全
访问者通过磁卡访问住宅。
Card_Access
……
……
……
……
2.1.6领域非功能特征词库
领域非功能特征词库中包含特征模型中非功能特征名称。
非功能特征名称采用名词(或名词词组)的命名规则。
例如:
安全性。
领域非功能特征词库用表格形式表示如下:
名称
所属领域
描述
分类标识符
安全性
住宅安全
系统避免处于潜在危险或不稳定状态的能力。
Security
……
……
……
……
2.1.7领域硬件特征词库
领域硬件特征词库中包含特征模型中硬件特征名称。
直接用硬件名作为领域硬件特征名称。
例如摄像头。
例如:
安全性。
领域硬件特征词库用表格形式表示如下:
名称
所属领域
描述
分类标识符
摄像头
住宅安全
一种视频输入设备
Camera
……
……
……
……
2.2描述领域需求
通过特定格式的领域需求描述格式,结合由领域从业人员抽取的领域词汇,对相关领域的需求进行描述。
在此基础上形成固定的可分析的需求描述文档,可用于自动化转换形成时序图、用例以及抽取形成特征模型框架。
2.2.1领域需求描述格式
采用自然语言对需求进行描述。
所描述的需求应具有以下特点:
●完整性
每一项需求都必须将所要实现的功能描述清楚,使开发人员获得设计和实现这些功能所需的全部必要信息。
●正确性
每一项需求都必须准确地描述其开发的功能。
●可行性
每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
●必要性
每一项需求都应该是客户真正所需要的和最终系统所遵从的标准记录。
●无二义性
对所有的需求说明都只有一个明确的统一的解释。
●可验证性
检查一下每项需求是否能通过设计测试用例或其它的验证方法。
为了让用自然语言描述的领域需求具有以上特点,我们定义了需求句型与需求文档间的关系,需求句型包括有独立句型、修饰句型句型、组合句型,用以描述领域需求:
独立句型包括:
∙功能动作句型名词+功能动词+(名词,)*
|功能动作句型+量化句型
∙非功能句型名词+非功能动词+(非功能名词,)*
|非功能句型+量化句型
修饰句型包括:
∙场景句型当+功能动作句型+时
|当+功能动作句型+后
|当+功能动作句型+量化句型+后,
∙量化句型数字+量词。
*量化句型使用仅能用在其它句型后面,做附加说明
组合句型:
∙描述句型Rn编号+(场景句型)?
+(功能动作句型|非功能句型)?
+(量化句型)?
∙需求描述编号+名称+描述句型*
∙需求描述文档(需求描述)*
句型中词语意思说明:
名词:
从领域名词库中选择。
非功能名词:
从领域非功能特征词库中选择。
动词:
从领域功能动词库或领域非功能动词库中选择。
功能动词:
从领域功能动词库中选择。
非功能动词:
从领域非功能动词库中选择。
如果对应词库中没有,则需要进行相应添加。
连接词:
和|或|且|……,用于连接多个功能动作句型或者多个名词。
量词:
秒|转|次|级|帕|伏|……
需求描述句型中场景句型、功能动作句型或非功能句型以及量化句型至少选用一个句型。
2.2.2领域需求示例:
呼吸机领域需求描述示例如下。
2.3特征模型
特征是系统中用户可见的、显著的或具有特色的方面、品质、特点等。
特征的识别主要是通过对已有的领域知识进行抽象来完成的,领域知识则来源于领域专家,书籍,用户手册,设计文档和源代码等各种信息源。
特征可以是应用系统提供的服务,应用系统的性能,应用系统需要的硬件平台、费用及其他相关信息等。
特征模型是对一个特定领域的软件所具有的特征的有组织的描述,主要记录了特征自身具有的重要属性和特征之间存在的各种关系。
特征模型主要包括:
●通过组成关系形成的特征层次分解图,即特征树;
●每个特征的变化性类型和绑定时间属性;
●每个特征的具体描述;
●特征之间存在的约束关系。
2.3.1特征树
特征模型主要由特征树组成,特征在特征模型中的表示方法如表2.1所示:
表2.1特征图例表
分类
命名
图例
功能特征
名词(或名词词组)+动词的命名规则,其中名词在领域名词库中有记录,动词在领域功能动词中有记录。
非功能特征
名词(或名词词组)的命名规则。
硬件特征
直接用硬件名作为硬件特征名称
特征树中元素可划分为:
●分解关系
分解关系是特征之间的主要关系。
一个父特征可以分解为一系列的子特征。
通过分解关系,特征以一种树状的层次结构被组织在一起。
分解关系包括可选特征与必选特征。
在特征模型中,用实线连接父特征和子特征。
呼吸机功能特征包含了几个功能特征图例如下所示图2.2内的上图所示,如果还要对其中的特征进行分解,则图号为父图图号开头,加上该图分解层次序号,如下所示图2.2内的下图所示。
图2.2分解关系示例
⏹可选特征:
指对于领域中的各个应用系统可有可无的特征。
如呼吸机可不包括显示屏。
⏹必选特征:
指在领域中每个应用系统中都应该包含的特征,如呼吸机必须包括提供气流这个特征。
●特殊化关系
特殊化关系包含以下两种关系,多选多关系以及多选一关系。
⏹多选多关系
多选多关系是对某一个一般性特征的特殊化。
在特征模型中,经常会出现一个特征下面有多个特殊化的特征,均具有同一种性质。
如报警特征下,可再细化成声音报警、灯光报警以及震动报警。
访问控制特征可特殊化为磁卡访问、密码访问。
但该类又与传统的对象特化不同,因为报警特征又可同时具有声音报警与灯光报警。
另外访问控制可同时具有磁卡访问与密码访问。
因此,在进行多选多关系的选择时,必须先确定是否这类备选的特征都具有相同的特征,即是否为均同一特征的特殊化,才能进行多选多操作。
该关系采用
,如图表示方式如下:
图2.3多选多关系
⏹多选一关系
多选一关系是对某一个一般性特征的具体化。
当某类特征被特殊化后仅选择其中一种时,则可以采用另一种表示形式
。
例如室外运动检测和室外视频检测室多选一特征,可表示为如下。
图2.4多选一关系
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.5所示:
图2.5住宅安全系统部分特征图
其中每个特征的详细描述如表2.3所示:
表2.3住宅安全控制相关特征的描述
特征名称
特征描述
住宅安全控制
是对整个住宅安全进行控制,进一步包含室内检测、访问控制、入侵检测等子特征。
室内监视
利用摄像头对室内的环境进行监视。
包含一对多选一的特征:
视频监视、室内运动监视。
访问控制
对进入住宅的访问者进行识别。
包含一对多选多的特征:
磁卡访问、密码访问。
入侵监视
对采用其他方式进入住宅的访问者进行监视。
包含破窗检测和一对多选一的特征:
室外视频监视、室外运动监视。
室内视频监视
对室内进行监视,有异常发出警报。
室内运动检测
对室内运动物体进行检测。
磁卡访问
访问者使用磁卡进行访问。
密码访问
访问者使用密码进行访问。
破窗检测
对窗户完好度进行检测。
室外运动检测
对室外的运动物体进行检测。
室外视频检测
对室外进行视频监视。
摄像头
在进行室内视频监视和室外视频监视时需要用到的摄像头硬件。
安全性
是住宅安全系统的安全性。
反应时间
是住宅安全系统对异常出现作出相应动作的反应时间。
特征文本描述如下所示:
F1住宅安全控制:
all(访问控制,入侵检测,室内监视?
)
F2访问控制:
more-of(磁卡访问,密码访问)
F3入侵检测:
all(破窗访问,one-of(室内运动检测,室外视频检测))
F4室内监视:
one-of(室内视频监视,室内运动检测)
F5室内视频监视:
requires(摄像头)
F6室外视频监视:
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
……
……
……
3.特征的过程式优化
功能特征与非功能特征均与功能相关,而随着分析设计以及实现各阶段的不同。
所关联的功能或实现才会逐步清晰或是被细分。
因此,需要引入分阶段对特征的优化方法。
3.1非功能特征
任何非功能特征具有属性、约束性质、形成来源三个部分。
非功能特征又可分为常态非功能特征与动态非功能特征。
Ø常态非功能特征如下:
1由于具有长60宽60,从而具有非功能特征为正方形。
2由于采用无锈钢外壳,从而具有非功能特征为白色
3由于要内含软件,从而具有ROM空间占用率。
Ø动态非功能特征则需要执行形成动作才能体现出来的非功能特征,如
1运行软件,具有非功能特征---运行时间
2运行某功能模块,具有非功能特征CPU消耗率
其中仅有动态非功能特征的形成来源与系统开发技术相关。
在领域需求时必须为空,等待在领域的分析、设计、实现中分阶段逐步进行填充修正。
在测试时执行该形成来源,完成非功能特征的体现,并与约束性质进行对比,是否符合约束性质的规定。
常态非功能特征则必须在领域需求时必须填充完毕,在测试时与约束性质进行对比,验证是否符合规定。
各相关过程,均须补充该功能的相关操作。
3.2功能特征
任何功能特征具有属性、约束性质、形成来源三个部分。
由于功能特征对应的模块会不断地分析细化甚至是修改变更,因此在领域需求描述时不可填写,必须等待在领域的分析、设计、实现中分阶段逐步进行填充修正。
在测试时可执行该形成来源,完成功能特征的体现,并与约束性质进行对比,是否符合约束性质的规定。
各相关过程,均须补充该功能的相关操作。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 领域需求建模规范0329 领域 需求 建模 规范 0329