快捷搜索:

UML业务建模实例分析

对付大年夜中型信息系统,很难直接进行需求阐发设计,必要借助模型来阐发设计系统,根据系统调研数据,建立起目标系统的逻辑模型。

在软件工程的历史中,很长光阴里人们不停觉得需求阐发是全部软件工程中最简单的一个步骤,但在以前十年中越来越多的人熟识到它是全部历程中最为关键的一个历程。要是在需求阐发时阐发者们未能精确地熟识到客户的需求的话,那么着末的软件实际上弗成能达到客户的要求,或者导致需求的频繁变化,而软件无法在规定的光阴里竣工。

在需求阐发阶段,要对颠末可行性阐发所确定的系统目标和功能作进一步的具体叙述,确定系统“做什么?”的问题,终极建立起目标系统的逻辑模型。

首先是获适合前系统的物理模型。物理模型是对当前系统的真实写照,可能是一个由人工操作的历程,也可能是一个已有的但必要改进的谋略机系统。首先是要对现行系统进行阐发、理解,懂得它的组织环境、数据流向、输入输出,资本使用环境等,在阐发的根基上画出它的物理模型。然后抽象出当前系统的逻辑模型。

逻辑模型是在物理模型根基上,去掉落一些次要的身分,建立起反应系统本色的逻辑模型。接下来建立目标系统的逻辑模型。经由过程阐发目标系统与当前系统在逻辑上的差别,建立相符用户需求的目标系统的逻辑模型。着末弥补目标系统的逻辑模型。对目标系统进行弥补完善 ,将一些次要的身分弥补进去,例如掉足处置惩罚等。

UML(The Unified Modeling Language,即统一建模说话)是一种体例系统蓝图的标准化说话,可以对繁杂的系统建立可视化的系统模型,今朝已经被工业标准化组织OMG(Object Management Group)吸收,一经推出便获得许多闻名的谋略机厂商如Microsoft、HP、IBM、Oracle等的支持,也在慢慢开始利用到需求阐发历程中。

在应用UML建立当前系统逻辑模型历程中,初学者平日会碰到一些问题:

1.什么时刻真正必要营业模型?什么时刻用例模型自力存在?

2.在进行正确的营业建模时能用哪些UML图形?若何知道是否用顺序图或者交互图?

3.营业模型若何涉及到其他模型(如领域模型,用例模型等等)呢?若何有机地组织这些模型?

本文将经由过程藏书楼治理系统这个简单而范例的实例来进行一次UML需求阐发实践之旅。

许多读者对藏书楼图书治理工作对照认识,主如果环抱读者、图书和事情职员的借还书展开事情。我们先看看藏书楼事情职员和部分读者的需求。

读者来藏书楼借书,可能先查询书库的图布告录。查询可以按书名、作者、图书编号、关键字查询。查询有两种结果,假如查到则记下书号,交给事情职员,然后期待解决借书手续。假如该书已经被整个借出,则可做借书挂号,等待有书时被看护。假如藏书楼没有该书的记录,则做缺书挂号。

解决借书手续时先要出示图书证,没有图书证则去申请图书证。假如借书数量越过规定,则提示“借书数量超限,不能继承借阅”。事情职员挂号借阅人信息、借阅的图手札息、借出光阴和应还书光阴。系统自动改动书库的图布告录、读者库信息。

当一位读者还书时,事情职员根据图书证编号,找到读者的借手札息,查看是否超期,假如已经超期,则进行超期处罚。

假如图书有破损、损掉,则进行破损处罚。清除借阅记录,同时系统自动查看是否有等待借阅挂号,假如有则发出看护,改动书库记录,该书设置为已预订状态,否则设置为可借状态。

图书采购职员进行图书采购时,要参考种种图书的库存数和借阅率,留意合理采购。假如出缺书挂号则随时进行采购。正在采购的图书组成一个采购中书库。

采购到货后,进行验收,编号,同时加入图书库,改动采购中书库,并且查看订阅库,发出到书看护,并且已经改动书库的图布告录为已预订状态。

借书挂号是当欲借的书被借空后,读者志愿选择的一种操作,它应该记录读者名和联系要领,一旦有这本书后可看护读者。

到书看护,当读者预订的书来到之后,按照读者给出的联系要领发出看护。

缺书挂号是当读者必要的书库内查询没有记录时,将此信息转入缺货库,看护采购员采购。

图书注销,假如图书损掉或旧书淘汰,则将该书从书库中清除。

根据需求描述收拾一张需求表:

需求阐发时首先要识别出系统的介入者,在简单的藏书楼治理系统中,可以划分出两种介入者:读者和治理员。当然,根据营业的繁杂程度,介入者也可以进行细分,比如读者可以再分为门生读者、西席读者、校外读者,治理员根据营业和权限的不合可以再细分为库房治理员、借还书操作员、系统掩护职员、藏书楼治理职员等不合角色。在这里,为了简化处置惩罚,我们只列出了读者和治理员。对介入者描述如下:

(1)读者

描述:读者可以借阅、预定、了债物理书刊,可以对册本和小我信息进行查询,可以取消预定,可以提出办卡申请。

示例:持有借阅卡的任何人和组织。

(2)治理员

描述:图书治理员对系统进行掩护,包括读者信息的创建、改动、删除,书刊信息的掩护,条款信息的掩护,还有系统信息的掩护。

示例:图书治理员。

经由过程识别的介入者,对需求进一步阐发,将营业需求进行分化,得到每个介入者的应用用例。在本例中,我们可以获得以下用例:

1.册本借出:供给借阅物理书刊的功能。

2.册本了债:供给了债物理书刊的功能。

3.读者办卡:供给为读者解决借阅卡的功能。

4.预定书刊:供给对某一个种类的书刊的预约功能。

5.取消预定:供给对预定进行取消的功能。

6.册本查询:为读者供给网上的册本查询功能。

7.信息查询:为读者供给信息查询的功能。

8.读者信息掩护:供给读者信息的录入、改动、查询、删除的功能。

9.书刊信息掩护:供给物理书刊的录入、改动、查询、删除的功能。

10.条款信息掩护:供给书刊条款的录入、改动、查询、删除的功能。

11.系统信息掩护:供给对系统的参数的设置。

12.登录:治理员必要先登录才能进入系统。

并且,可以画出如下系统用例图:

经由过程用例图,可以对系统功能有一个大年夜概的懂得,对付繁杂系统,我们可以结合IDEF措施,经由过程分层分化,慢慢细化的措施来描述系统的功能。对付用例图,建议不要画的过于繁杂,分外是用例之间的关系,由于繁杂的用例图不仅不能让需求阐发职员与客户之间更好的沟通,反而是制造了一种沟通障碍。

下一步便是体例每一个用例的具体阐明,对用例阐明的主要信息包括有:用例名称、编号、用例的简短描述、用例的介入者、与其他用例的治理、用例启动的条件前提、用例停止后的事后前提、用例的输入、输出、用例的履行事故流等。在实际项目中,我们并不必然要面面俱到,而是根据实际环境对用例描述进行裁减。此中有几点紧张信息是不能裁减的:用例名称、描述、输入、输出、履行事故流、介入者。别的,假如实际环境必要,还可以应用MS Visio等对象画出界面的示意图来。

如上例所述,我们对每一个用例都进行具体的描述,建立当前系统的功能用例模型。需求沟通与阐发是一个迭代的历程,经由过程与用户的赓续沟通,终极杀青对目标系统的同等理解。假如用户确认了需求阐发的成果,一样平常是需求规格阐明书之后,项目开始进入系统阐发设计阶段,也便是开始构造目标系统的逻辑模型。

为了让系统设计能够以布局、组织要领和代码重用的形式体现出来,要对系统进行设计筹划,设计阶段应该与阐发阶段交迭。需求是赓续地成长,而设计本身也会推动需求的成长(反之亦然) 。在藏书楼治理系统的建模设计中,以下3个方面的问题是要关注的:营业工具的表示、营业办事的实现、用户界面的组织。

营业工具的表示

在藏书楼治理系统系统中,营业工具主如果数据库和数据实体类的表示要领。建模时,可以构造出系统的静态模型,也便是系统类图来表示。如下图则描述了借书这一用例的静态布局图。为了表现类之间的关系,鄙人图中没有显示出每一个类的属性和基础操作。

营业办事的实现

营业办事的实现必要完成的功能是各类营业规则和逻辑的实现,如借书处置惩罚的营业逻辑。每个模块的信息录入、改动、删除、查询等。营业规则和逻辑的实现基真相似,没有太多的规律可循。采纳UML来进行营业办事的建模,可以应用UML 的序列图、状态图、活动图。这个部分的事情,平日经由过程一系列的类之间的交互来完成。为了在更动态的层面上描述系统,UML 供给了许多其他类型的图。

对付B/S系统设计而言,情节图(Scenario Diagram) 分外有用。情节图分成两种:协作图(Collaboration Diagram) ,序列图(Sequence Diagram) 。UML 建模对象Rational Rose 能够从协作图天生序列图也可以从序列图天生协作图。例如,借阅书刊的营业历程可以采纳如下序列图来描述:

借阅书刊历程主要包括:治理员选择“借阅书刊”菜单,弹出对话框,治理员输入书刊信息和用户信息,系统查找数据库,是否存在该种物理书刊,假如不存在,显示提示信息,用例停止;是否存在借阅者信息,假如不存在,显示提示信息,用例停止;否则,治理员单击确认按钮后,该图书借阅给该借阅者,系统存储借阅信息到数据库。

用户界面的组织

用户界面结构图能够赞助组织系统页面、文件、办事的结构布局。在UML 中,对付页面和文件的组织,可以应用构件图(Component Diagram) 或类图(Class Diagram) 建模型。本系统中应用类图对界面组织建模,页面布局以及各类营业办事被绑缚到不合的区域。

在 UML 中,系统的体系布局应用支配图(DeploymentDiagram) 来完成。利用支配的筹划对付筹划全部B/ S 系统是很有用的。它确定了一种有效的利用支配的筹划组织要领,还可以作为一个模式在多个类似B/ S 系统上利用。

在建模完成后,开拓职员使用一些UML Case对象如Rational ROSE天生法度榜样代码框架,并对代码框架进行改动和弥补,形成完备代码;而且,还可根据代码逆向天生 UML模型。这就较好地包管了模型与代码的同等性。

测试必须在全部项目周期中进行,对每个阶段都要用所建立的模型进行测试,这样才能包管开拓的质量,削减开拓的风险。

统一建模说话 UML 是国际软件工程领域具有划期间意义的紧张成果,适用于以面向工具技巧来描述任何类型的系统,而且适用于系统开拓的不合阶段,从需求规格描述直至系统完成后的测试和掩护。软件系统的规模越来越大年夜,繁杂度赓续前进,RUP迭代式增量开拓要领可以低落风险,同时可以适应需求变更的必要。

在本次UML实践之旅中,我们经由过程对藏书楼治理系统的需求进行阐发,将 UML 利用于系统开拓的各个阶段,建立了系统的需求模型、静态模型和动态模型,同时遵照Rationl统一历程(RUP)的核心思惟和基滥觞基本则,采纳以用例为驱动、以体系构架为核心的迭代化面向工具阐发和设计历程。

图1:系统用例图

图2:用况活动图

图3:借书部分的类布局图

UML行径图

用况图(use case diagram)描述了一组用况和介入者(一种特殊的类)以及它们之间的关系。

交互图(interaction diagram)是顺序图和协作图的统称。

顺序图(sequence diagram)是强调消息的光阴序次的交互图。

协作图(collaboration diagram)是强调收发消息的工具的布局组织的交互图。

状态图显示了一个由状态,转换,事故和活动组成的状态机。

活动图显示了系统中从活动到活动的流。

您可能还会对下面的文章感兴趣: