一种基于UML动态模型的系统类结构生成方法与流程

文档序号:15635980发布日期:2018-10-12 21:28阅读:167来源:国知局

本发明涉及系统建模领域,特别是涉及一种基于uml动态模型的系统类结构生成方法。



背景技术:

uml是一种标准的建模语言,在面向对象的系统设计和系统开发方法中,“类”模型是整个设计和开发方法的核心。“类结构”用于描述系统“类”的组成,以及“类”的方法、接口、属性等,是面向对象设计和开发的基础。

uml规范中定义了“活动图”、“时序图”、“状态图”,用于辅助设计人员开展“类”,以及“类”的“变量”和“方法”的分析。但是uml并未严格规范“活动图”、“时序图”、“状态图”的映射关系,因此在实际建模分析过程中,非常依赖设计人员的经验、能力。当系统庞大时,对模型分析所带来的工作量也十分庞大,且容易出现错误。



技术实现要素:

本发明主要解决的技术问题是提供一种基于uml动态模型的系统类结构生成方法,能够根据描述业务场景的系统动态模型,生成类结构,满足快速、高效、准确建立系统类结构模型的要求,可指导基于面向对象的系统设计、开发过程中类结构的设计。

为解决上述技术问题,本发明采用的技术方案为:提供基于uml动态模型的系统类结构生成方法,主要包括如下步骤:

1)开展系统业务分析,通过uml的“活动图”、“时序图”和“状态图”,建立系统业务模型,在活动图中建立“泳道”模型、“活动”、“数据流模型”模型,在时序图中建立“生命线”模型、“事件”、“消息模型”,在状态图中建立“状态”和“转移规则”模型;

2)按照面向对象的思想,对所有“活动图”、“时序图”和“状态图”模型进行语法分析,从“泳道”模型、“生命线”模型提取“对象”模型,同时为每一个状态图定义一个“对象”模型,从而形成“对象集合”;

3)从“对象集合”的“对象”抽象出“类”,生成类集合;

4)从步骤2)中提取的“对象”视角出发:通过对所有“活动图”中“泳道”模型下的“活动”模型分析,提取“对象”的“操作”要求;通过对所有“时序图”中“生命线”模型下“事件”模型分析,提取“对象”的“操作”要求;通过对所有“状态图”中“状态”和“转移规则”模型分析,提取“对象”的“操作”要求;

5)通过对“活动图”中的“数据流”模型分析,提取“对象”的“数据接口”和“类属性”;通过对“时序图”中“消息”模型分析,提取“对象”的“数据接口”和“类属性”;通过对“状态图”中“转移规则”模型分析,提取“对象”的“数据接口”和“类属性”;

6)将步骤4)中提取的“对象”的“操作”要求映射为类的“方法函数”;将步骤5)中提取的“数据接口”映射为类的“方法/接口/函数”和“类变量”,“类属性”要求映射为“类变量”;

7)根据步骤3)中获得的“类集合”信息,根据步骤6)生成的“方法函数”、“类变量”信息生成类结构图,所述类结构包括类组成、各个类的方法/函数、接口和类变量。

优选地,所述步骤1)中建立的“活动图”、“时序图”和“状态图”模型基于uml2.0规范,通过定义参与业务流程的角色/对象,及各个角色/对象的关键活动、事件方式描述业务场景。

优选地,所述步骤2)具体包括:基于uml2.0规范,将“活动图”中每个“泳道”模型映射为一个“对象”模型,名称相同的“泳道”视为同一个“对象”;将“时序图”中每个“生命线”模型映射为一个“对象”模型,名称相同的“生命线”视为同一个“对象”,从而形成“对象集合”,同时将该“对象”关联一个“状态图”,将每一个“状态图”与一个“对象”模型绑定。

优选地,所述步骤3)具体包括:将步骤2)中“活动图”、“时序图”中提取的“对象”模型及状态图关联的“对象”通过模型名称、特性、约束三个条件进行比对,将相同的模型进行合并,形成“类”集合。

优选地,所述步骤4)具体包括:遍历所有活动图,将同一“对象”对应的“泳道”模型下的“活动”模型映射为该“对象”的“操作”要求;遍历所有时序图,将同一“对象”对应的“生命线”模型下的“活动”模型映射为该“对象”的“操作”要求;遍历所有状态图,将同一“对象”对应的“状态”和“转移规则”模型映射为该“对象”的“操作”要求。

优选地,所述步骤5)具体包括:遍历所有“活动图”,从“数据流”模型提取“对象”的“数据接口”和“类属性”;遍历所有“时序图”,从“消息”模型提取“对象”的“数据接口”和“类属性”;遍历所有“状态图”,从“转移规则”模型提取“数据接口”和“类属性”。将同一对象下名称相同“数据接口”和“类属性”进行合并,消除重复。

本发明的有益效果是:1)基于uml提出描述业务流程的动态建模要求和规范;2)定义动态模型中部分模型与类结构的映射关系;3)定义动态模型中部分模型与类的接口、方法和属性的对应关系;4)定义从动态模型生成系统的静态类结构;通过验证,本发明方法可以根据复杂系统动态模型生成系统类结构,通过生成方法,可指导面向对象的系统设计、开发。

附图说明

图1是本发明提供的一种基于uml动态模型的系统类结构生成方法流程图;

图2a为人取款时atm机系统的活动图;

图2b为人取款时atm机系统的时序图;

图2c为人取款时atm机系统的状态图;

图3是本发明提供的一种基于图2a至2b所生成的类结构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白,下面将结合发明实施例中的附图,对发明实施例中的技术方案进行清楚、完整地描述,显然,下面所描述的实施例仅仅是发明一部分实施例,而非全部的实施例。基于发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于发明保护的范围。

图1是本发明提供的一种基于动态模型的系统类结构生成方法的算法流程图。

在步骤101中,开展系统业务分析,通过uml的“活动图”、“时序图”和“状态图”,建立系统业务模型,在活动图中建立“泳道”模型、“活动”、“数据流模型”模型,在时序图中建立“生命线”模型、“事件”、“消息模型”,在状态图中建立“状态”和“转移规则”模型。其中,建立的“活动图”、“时序图”和“状态图”模型基于uml2.0规范,通过定义参与业务流程的角色/对象,及各个角色/对象的关键活动、事件方式描述业务场景。建模完成后,按照uml2.0的模型描述规范xmi,将模型存储到本地文件中。

“活动图”中“泳道”模型是描述一个“对象”的主要流程;“时序图”中“生命线”模型是描述一个“对象”的交互状态;每个“状态图”是描述一个“对象”状态变化,因此,根据“泳道”模型、“生命线”模型可提取“对象”模型,每一个状态图对应一个“对象”模型。

在步骤102中,按照面向对象的思想,对所有“活动图”、“时序图”和“状态图”模型进行语法分析,从“泳道”模型、“生命线”模型提取“对象”模型,同时为每一个状态图定义一个“对象”模型,从而形成“对象集合”。

具体地,基于uml2.0规范,将“活动图”中每个“泳道”模型映射为一个“对象”模型,名称相同的“泳道”视为同一个“对象”;将“时序图”中每个“生命线”模型映射为一个“对象”模型,名称相同的“生命线”视为同一个“对象”,从而形成“对象集合”,同时将该“对象”关联一个“状态图”,将每一个“状态图”与一个“对象”模型绑定。

在步骤103中,从“对象集合”的“对象”抽象出“类”,生成类集合。其中,同一对象的名称、特效、约束应相同,若三者相同,可视为同一“对象”或“类”。因此,通过模型名称、特性、约束三个条件进行比对可,将相同的模型进行合并,形成“类”集合。

在步骤104中,从步骤102中提取的“对象”视角出发:通过对所有“活动图”中“泳道”模型下的“活动”模型分析,提取“对象”的“操作”要求;通过对所有“时序图”中“生命线”模型下“事件”模型分析,提取“对象”的“操作”要求;通过对所有“状态图”中“状态”和“转移规则”模型分析,提取“对象”的“操作”要求。

“活动图”中“泳道”下的“活动”描述对象的关键活动或操作;“时序图”中“生命线”下“活动”模型描述对象的关键行为或操作;“状态图”中“状态”和“转移规则”描述对象的关键操作和状态。因此,遍历所有活动图,将同一“对象”对应的“泳道”模型下的“活动”模型映射为该“对象”的“操作”要求;遍历所有时序图,将同一“对象”对应的“生命线”模型下的“活动”模型映射为该“对象”的“操作”要求;遍历所有状态图,将同一“对象”对应的“状态”和“转移规则”模型映射为该“对象”的“操作”要求。

在步骤105中,通过对“活动图”中的“数据流”模型分析,提取“对象”的“数据接口”和“类属性”;通过对“时序图”中“消息”模型分析,提取“对象”的“数据接口”和“类属性”;通过对“状态图”中“转移规则”模型分析,提取“对象”的“数据接口”和“类属性”。

“活动图”中的“数据流”模型描述对象的之间的交互;“时序图”中“消息”模型描述对象之间的操作和交互;“状态图”中的“转移规则”描述对象的外部触发事件。因此,遍历所有“活动图”,从“数据流”模型提取“对象”的“数据接口”和“类属性”;遍历所有“时序图”,从“消息”模型提取“对象”的“数据接口”和“类属性”;遍历所有“状态图”,从“转移规则”模型提取“数据接口”和“类属性”。

在步骤106中,将步骤104中提取的“对象”的“操作”要求映射为类的“方法函数”;将步骤105中提取的“数据接口”映射为类的“方法/接口/函数”和“类变量”,“类属性”要求映射为“类变量”。

在步骤107中,根据步骤103中获得的“类集合”信息,根据步骤106生成的“方法函数”、“类变量”信息生成类结构图,所述类结构包括类组成、各个类的方法/函数、接口和类变量。

以下结合图2a-2c和图3具体说明:

一、根据对系统的典型业务场景分析,分析系统的关键活动,然后基于uml2.0规范,通过“活动图”描述参与业务流程的业务对象的关键活动或操作,如图2a)所示为用户通过atm取款的活动图,所述内容如下:

1、银行客户插入银行卡;

2、atm读取器类识别卡的真伪,如果是不符合则退卡,结束流程;如果符合则进入下一个活动;

3、atm读取器类获取银行卡信息;

4、账户管理类负责打开输入密码的窗口;

5、银行客户在提示窗输入密码,并由交互类将密码信息交由账户管理类进行验证,如果输入3次不成功则退卡,结束流程;如果验证成功,则进入下一个流程;

6、系统向银行客户提供业务操作窗口;

7、银行客户选择取款,输入金额;

8、交互类负责将取款金额传递与账户管理类;

9、账户管理类通过银行系统查询账户余额,如果取款金额大于账户余额,则提示客户,同时返回到业务操作界面;如果取款金额小于等于账户余额,则控制atm输出·钞票,同时修改账户余额;

10、银行客户取走现金。若在30s内未取卡,则系统执行吞卡。否则正常结束。

二、用户根据系统的典型业务场景分析,分析系统关键流程及对象之间的交互规则,然后基于uml2.0规范,通过“时序图”描述参与业务流程的业务对象交互及其时序关系,如图2b)所示为用户通过atm取款的时序图,所述内容如下:

1、银行客户向读卡类输出银行卡,读卡类获取银行卡信息,并输出给账户管理类;

2、账户管理类获取该账户对应的密码信息,输出给交互类,交互类向银行客户输出密码输入窗口,并根据客户输入情况进行匹配;

3、银行客户将输入密码信息至交互类,交互类将密码信息输出至银行系统;

4、银行系统确认后,向账户管理类输出合法性信息;

5、交互类通过界面向银行客户输出服务种类;

6、银行客户通过界面向交互类下达取款指令及取款金额,交互类将操作指令输出至账户管理类;

7、银行系统检查输入的合法性。若合法,向金额管理类下达出钞请求;

8、银行客户取钞后,向交互类下达退卡指令;

9、交互类将退卡申请传递至账户管理类,由账户管理类确认后,进行退卡操作。

三、用户根据各个对象的关键活动和交互规则,分析各个对象的状态,然后基于uml2.0规范,通过“状态图”描述对象的状态转移规则,如图2c)所示为读卡类的状态转移规则,所述内容如下:

1、读卡类默认处于待机状态;

2、当插入卡片为银行卡且插入方式正确,进入读卡成功状态;

3、若插入卡片非银行开或插入方式错误,则进入读卡失败状态;

4、若输入三次密码错误,则进入吞卡状态。之后自动进入待机状态。

四、建模完成后,从“活动图”中提取参与的“对象”模型,包括“银行客户”、“读卡类”、“交互类”、“操作响应与处理类”、“账户管理类”、“金融管理类”、“银行系统”。从“时序图”中提取参与的“对象”模型,包括“银行客户”、“读卡类”、“交互类”、“操作响应与处理类”、“账户管理类”、“金融管理类”、“银行系统”。并按照名称进行合并,生成对象集合包括:“银行客户”、“读卡类”、“交互类”、“操作响应与处理类”、“账户管理类”、“金融管理类”、“银行系统。例如,将“读卡类”对象与图2c)的“状态图”进行关联。

五、从对象集合中抽象出类,生成类集合,包括:“读卡类”、“交互类”、“操作响应与处理类”、“账户管理类”、“金融管理类”。

六、从“对象”视角出发:对“活动图”中每个“泳道”模型下的“活动”模型分析,提取“对象”的“操作”要求,对所有“时序图”中“生命线”模型下“事件”模型分析,提取“对象”的“操作”要求,包括:

1、读卡类:读取卡号信息、退卡、吞卡;

2、交互类:显示输入密码要求、显示选择操作界面、显示账号余额;

3、操作响应与处理类:传递密码、传递取款金额;

4、账号管理类:根据卡号查询密码、请求验证密码、请求确认取款金额;

5、金额管理类:接收银行扣款指令、出钞。

七、遍历“活动图”,从“数据流”模型提取“对象”的“数据接口”和“类属性”。遍历所有“时序图”,从“消息”模型提取“对象”的“数据接口”和“类属性”;遍历所有“状态图”,从“转移规则”模型提取“数据接口”和“类属性”,

其中,“类属性”包括:

1、账号类:账号、密码、余额;

2、读卡类:卡号、银行名称、芯片标志;

3、账号管理类:用户名、密码。

“数据接口”包括:

1、账号类:打开、查询、取款;

2、交互类:显示操作界面、接受用户输入、显示信息、显示请求;

3、操作响应与处理类:返回、输入密码、选择操作、确认;

4、读卡类:鉴别卡的真伪、接受卡、退卡、读卡、吞卡;

5、账号管理类:链接成功、链接失败、查询密码、请求验证;

6、金额管理类:计算余额、提供现金、打印凭条。

八、将“操作”要求和“数据接口”映射为类的“类方法”,“类属性”映射为“类变量”。

其中,“类变量”包括:

1、账号类:账号、密码、余额;

2、读卡类:卡号、银行名称、芯片标志;

3、账号管理类:用户名、密码。

“类方法”包括:

1、账号类:打开、查询、取款;

2、交互类:显示操作界面、接受用户输入、显示信息、显示请求;

3、操作响应与处理类:返回、输入密码、选择操作、确认;

4、读卡类:鉴别卡的真伪、接受卡、退卡、读卡、吞卡;

5、账号管理类:链接成功、链接失败、查询密码、请求验证;

6、金额管理类:计算余额、提供现金、打印凭条。

九、根据上述的结果,生成类结构图,如图3所示。

本发明的有益效果是:1)基于uml提出描述业务流程的动态建模要求和规范;2)定义动态模型中部分模型与类结构的映射关系;3)定义动态模型中部分模型与类的接口、方法和属性的对应关系;4)定义从动态模型生成系统的静态类结构;通过验证,本发明方法可以根据复杂系统动态模型生成系统类结构,通过生成方法,可指导面向对象的系统设计、开发。

以上所述的具体实施方式,对本发明的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本发明的具体实施方式而已,并不用于限定本发明的保护范围,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1