面向对象分析与设计uml应用实例步骤详解.docx
《面向对象分析与设计uml应用实例步骤详解.docx》由会员分享，可在线阅读，更多相关《面向对象分析与设计uml应用实例步骤详解.docx（29页珍藏版）》请在冰豆网上搜索。
面向对象分析与设计uml应用实例步骤详解
《面向对象分析与设计》
实验参考资料
面向对象分析与设计
一、课程编号
本科软件工程
二、课程类型
课程类型：
必修课。
适用专业：
软件工程
试验学时：
10～24学时
三、本课程的地位、作用与任务
计算机软件建模技术现在越来越广泛的应用于软件工程中。
《面向对象系统分析设计》课程实验的目的是为了使学生在课程理论学习的同时，通过在一个实践的环境下，实际学习软件统一建模语言，对软件建模技术有一个初步的了解及认识。
通过本指导书中的各个实验，学习掌握对一般面向对象系统建模的方法与技术。
总之，通过上述实验环节，使学生加深了解和更好地掌握课程教学大纲要求的内容。
四、课程基本要求
1、学生应根据每个上机试验的任务和教师所提的要求，上机前准备好上机内容。
2、上机时要针对一个实际的案例进行分析，画出不同的阶段UML图。
3、上机结束后应按时提交试验报告，对于上机未完成部分，应该下机后利用课余时间完成。
五、实验安排
实验1：
实验准备
1．实验器材
1．计算机一台。
2．建模工具软件。
2．rationalrose安装步骤
（1）运行安装软件；
（2）单击下一步，选择rationalroseenterpriseedition；
（3）单击下一步，选择desktopinstallationfromcdimage，表示创建一个本地的应用程序而不是网络的；
（4）随后根据提示进一步操作，完成安装，注册；
（5）运行rationalrose，进入主界面，new表示新建模型，existing表示打开现有，recent表示最近打开模型；
（6）熟悉模型的创建，保存，发布。
实验2：
用例分析与设计
1、实验目的
1．熟悉用例图的基本功能和使用方法。
2．掌握如何使用建模工具绘制活动图方法。
2、实验内容
1.根据某图书馆的图书管理系统开发进度，在完成对系统的需求建模，得到用例模型后，应针对每个用例进行业务分析，说明其具体的业务流程，现系统分析部指派您完成该项任务。
要求：
2.对其中主要功能的用例书写书面用例。
3、实验步骤
书写“删除读者信息”用例的书面用例。
一般应包含以下信息：
（1）管理员在录入界面，输入待删除的读者名；
（2）“业务逻辑”组件在数据库中，查找待删除的读者名；
（3）如果不存在，则显示出错信息，返回步骤
（1），如果存在则继续；
（4）“业务逻辑”组件判断“待删除的读者”是否可以删除；
（5）如果不可以，则显示出错信息，返回步骤（8），如果可以则继续；
（6）在数据库中，删除相关信息；
（7）显示删除成功信息；
（8）结束。
分析:
在图书管理系统中,管理员首先登录系统,系统验证通过后,管理方可向系统查询数据,在查询后,系统会给出提示,有没有找到相关的数据,管理员根据系统查询的返回结果,进行下一步的操作,就是删除读者,在删除的过程中,系统会对查询得到的结果判断该记录是否可以删除,若可以删除,则给删除提示,若不能删除,也给相关的提示信息。
绘图步骤:
（1）在用例图上双击main,出现如图2.1所示,为绘制用例图做好准备。
图2.1
（2）在图中的工具栏选取Actor图标，在右边的图中添加一个Actor，并输入名称:
administrator,如图2.2所示。
（3）在左边的工具栏中，选取用例的图标，在右边的图中画出一个用例，并输入用例的名称：
login。
图2.2
（4）按照步骤（3），绘制出如图2.4和图2.5的两个用例。
图2.3
图2.4
图2.5
（5）在绘出了用例后，接下来的是绘制参与者与用例实现，如图2.6所示。
图2.6
（6）根据步骤（5），同时完成如图2.7和图2.8。
此时，删除读者用例图就到此完成。
其系统查询读者信息等其他的功能会在时序图和活动图中描绘。
（7）根据分析情况，进一步添加或细化用例图。
图2.7
图2.8
4、实验报告要求
1．可以细化、完善或者修改给出的例子，分析和设计用例图，写出实验步骤，整理实验结果。
实验操作和步骤尽量详尽，并且按照指导书给出的范例，适当进行需求和系统分析，做出的各种框图需要在实验报告中画出来，可以打印。
2．小结实验心得体会，对于遇到的问题给予分析。
实验3：
类图的设计
1．实验目的
1.掌握使用rose画类图的步骤。
2.掌握类图的基本语法。
2．实验内容
1.根据图书管理系统的需要分析，用例图，交互图，对系统进行静态建模，寻找和发现类，分析类之间的关系；
3．实验步骤
1．打开前面初步构建的UML模型文件;
2．打开Rose中的逻辑视图（LogicalView），选择分析模型（analysismodel）目录。
并在其下创建一个子目录并命名为：
“图书馆业务功能”。
3．用鼠标右击“图书馆业务功能”在弹出来的菜单中选择“New→Classdiagram”项，创建类图。
4．双击新建的类图，并点右边控件集中选中的类并用鼠标在图中分别拖出上述类图。
5．设定上述抽象出来各类的属性和操作。
6．分析、设定以上各类之间的关系。
7．请根据教材中示例部分在RationalRose中绘制类间的关系。
注意：
这里没有具体的相关的例子；
实验4：
状态图
1．实验目的
1．熟悉状态图的基本功能和使用方法。
2．掌握如何使用建模工具绘制状态图方法。
2．实验内容
1.通过某图书馆的图书馆管理系统的需求的初步分析，得出系统的用例图和相应的活动态。
通过这两类图我们可以初步了解系统的业务处理过程，但对业务处理过程的处理状态间转换了解仍不够，这不利于设计人员对系统业务的进一步理解，而状态图能从对象的动态行为的角度去描述系统的业务活动。
因此，指派你运用本节所学的状态图，完成如下任务：
2.完成图书业务模块中还书用例的状态图。
3．实验步骤
1．业务分析：
对图书馆管理系统中的还书主要业务的描述和分析可知，还书业务的动态行为是由：
空闲（idle）、图书查找（finding）、还书（reversion）、失败（Failure）、归还成功（Success）5种状态及激活相互转换的事件。
2．绘制状态图：
请您根据分析运用UML绘制还书用例的状态图。
分析：
还书的状态图，还书的主要业务都是由管理员来完成，首先管理员必须先登录系统，并通过验证后，便可以进行下一步的操作，查找该书的相关信息，如存在，则进行还书操作，如不存在该信息，则给出提示信息；
绘图步骤：
（1）在用例图中的还书（revesion）用例，单击右键，如图3.15所示，新建一个状态图，命名为revesion状态图，图3.16所示。
图3.15
图3.16
（2）双击“receivesion”状态图，展开后，在左边的工具栏上选取一个实心圆点，此结点为开始结点，图3.17所示；当还书的时候，操作者先要询问系统的状态，如果系统忙，操作者则必需等待，因此，得到系统的两种状态，如图3.19所示。
图3.17
图3.18
图3.19
（3）操作者在询问系统和状态后，得到的图3.20所示两种状态，如果系统忙，操作者必需要等待、结束，如图3.21和图3.22所示，重返步骤
（1）。
图3.20
图3.21
图3.22
（4）如系统空闲，则进行对还书的信息进行查询操作，图3.23所示；查询也有两种结果，一是查询得到该书的相关信息，二查询不到该书的相关信息；则此时有两种状态，需要建立两种状态，如图3.25所示。
图3.23
图3.24
（5）最后，操作者进行了操作后，系统会给出操作的结果给操作者；操作成功或失败，都会有提示信息给出。
整个的还书的过程便完成；
实验5：
时序图
1．实验目的
1．理解时序（顺序）图的基本概念。
2．掌握在RationalRose中绘制时序图的操作方法。
2．实验内容
1.对图书的相关操作完成时序图；
3．实验步骤
1．分析：
根据对图书业务功能模块中的时序图操作进行动态建模的操作步骤和方法，请你对书籍管理模块中的交互操作进行动态建模。
该模块中主要存在新增书籍、修改书籍信息和删除书籍三种交互操作。
2．请根据教材中示例部分在RationalRose中绘制上述的交互图。
绘图步骤：
（1）在Rose软件的左边栏目上的LogiclView单击右键，新建一个时序图，时序图是交互图一种表示，可以用时序来表示，如图4.1；在此，先单间介绍一下用法：
图中的直线箭头是发送消息；虚线箭头是返回消息；曲折线是对象自己给自己发送消息并调用。
（2）接下来的是添加类，系统中的类是其他的方法的边界，在上面做好的类找到可以直接拖拉来图中，见图4.2和图4.3所示。
图4.1
图4.2
图4.3
（3）添加类后，便可以添加方法了，开始是必需是外面的实体向系统发送消息，如图4.4所示，是管理员登录时向系统发送的消息；
图4.4
（5）可以按上一步的方法来完成其他的方法，如viladate（验证）,返回验证结果，当用户收到结果后，可以正常登录后便能进行增加图书见图4.5到图4.9。
最后得到的时序图如图4.10所示。
图4.5
图4.6
图4.7
图4.8
图4.9
图4.10
实验6：
协作图
1．实验目的
1．理解协作图的基本概念。
2．掌握在RationalRose中绘制协作图的操作方法。
2．实验内容
1.通过对教学内容的学习，使我们完成了某图书馆的管理系统的需求分析，并从业务对象中抽象出了类。
现在需要对前面所给出的用例进行实现，主要是对书籍管理功能画协作图。
3．实验步骤
1．分析：
根据上面的时序图，我们也可以图出协作图。
2．请根据上面时序图部分在RationalRose中绘制协作图。
绘图步骤：
（1）完成了时序图后，可以按F5键便得到增加图书的协作图，也可以画出图4.11这样的协作图。
图4.11
（7）剩下的更新图书信息和删除图书信息的交互图在此不再一一详细的介绍，其绘图方法跟绘制增加图书的方法一样，最后得到见图4.12到图4.15
图4.12
图4.13
图4.14
图4.15
实验7，8：
综合设计实验
1．实验目的
1．掌握用RationalRose进行软件建模。
2．实验内容
1.对一个系统进行建模。
3．实验步骤
1.对系统进行完整的建模。
生成其用例图，状态图，活动图，时序图以及协作图。
鼓励创新。
2.可以选择的系统有：
本科生教务系统，图书管理系统，编译器，博客，即时通信软件等等。
六、教材
实验教材以本实验指导书为参考；
七、成绩考核办法
采用综合实验与撰写报告综合评分
八、附A：
完整UML建模过程例子
基于UML的面向对象分析与设计案例
介绍
本文以实例的方式，展示了如何使用UML进行面向对象的分析与设计。
本文将假设读者对UML、面向对象等领域的基本内容已了然于胸，所以将不会过多阐述，而将重点放在应用过程上。
本文的目的是通过一个完整的实例，展现基于UML的OOA&D过程的一个简化模式，帮助朋友们更好的认识UML在OOA&D中起的作用。
经常听到有朋友抱怨，说学了UML不知该怎么用，或者画了UML却觉得没什么作用。
其实，就UML本身来说，它只是一种交流工具，它作为一种标准化交流符号，在OOA&D过程中开发人员间甚至开发人员与客户之间传递信息。
另外，UML也可以看做是OO思想的一种表现形式，可以说“OO是神，而UML是型”。
所以，想用好UML，扎实的OO思想基础是必不可少的。
然而，在UML应用到开发过程中时，还是有一定的模式可以遵循的。
（注意，是模式而不是教条，我下面给出的流程只是一个启发式过程，而不是说一定要遵循这个流程。
）下面，我们通过一个CMS系统的分析设计实例，看看如何将UML应用到实际的开发中。
1.从需求到业务用例图
OOA&D的第一步，就是了解用户需求，并将其转换为业务用例图。
我们的CMS系统需求非常简单，大致课做如下描述：
这个系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。
任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。
管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。
通过以上需求描述，我们画出如下的业务用例图：
这里要注意三点：
1.业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。
它描述的是“该实现什么业务”，而不是“系统该提供什么操作”。
例如，在实际系统中，“登录”肯定要作为一个用例，但是这是软件系统中的操作，而用户所关注的业务是不包含“登录”的。
2.业务用例仅包含客户“感兴趣”的内容。
3.业务用例所有的用例名应该让客户能看懂，如果某个用例的名字客户看不懂什么意思，它也许就不适合作为业务用例。
2.从业务用例图到活动图
完成了业务用例图后，我们要为每一个业务用例绘制一幅活动图。
活动图描述了这个业务用例中，用户可能会进行的操作序列。
活动图有个很重要的使命：
从业务用例分析出系统用例。
例如，下面是“新闻管理”的活动图：
可以看到，一个“新闻管理”这个业务用例，分解出N多系统操作。
这里要特别注意这些操作，其中很多“活动”都很可能是一个系统用例（当然，不是每个都是）。
例如，由这个活动图可以看出，系统中至少要包含以下备选系统用例：
登录、注销登录、查看新闻列表、修改新闻、删除新闻。
这样，将每个业务用例都绘制出相应的活动图，再将其中的“活动”整合，就得出所有备选系统用例。
3.从活动图到系统用例图
找出所有的备选系统用例后，我们要对他们进行合并和筛选。
合并就是将相同的用例合并成一个，筛选就是将不符合系统用例条件的备选用例去掉。
一个系统用例应该是实际使用系统的用户所进行的一个操作，例如，“查看新闻列表”就不能算一个系统用例，因为他只是某系统用例的一个序列项。
最终我们得出的系统用例图如下：
4.从系统用例图到用例规约
得出系统用例图后，我们应该对每一个系统用例给出用例规约。
关于用例规约，没有一个通用的格式，大家可以按照习惯的格式进行编写。
对用例规约唯一的要求就是“清晰易懂”。
下面给出“登录”这个系统用例的一个规约：
5.绘制业务领域类图
完成了上面几步，下面应该是绘制业务领域类图了。
所谓业务领域类图要描述一下三点：
1.系统中有哪些实体。
2.这些实体能做什么操作。
3.实体间的关系。
这里要特别强调：
这里的实体不是Actor，而是Actor使用系统时使用的所调用的实体，是处在系统边界之内的实体。
例如，管理员就没有作为一个实体出现在这里，因为管理员处在系统边界之外，它所有的工作都可以通过调用这三个类的方法完成。
并且，这里的“注册会员”实体也不是刚才用例图中注册会员这个Actor，而是作为一个系统内的业务实体，供Actor们使用的。
例如，其中的注册功能是给注册会员这个Actor使用，而移除则是给管理员这个Actor使用的。
理解以上这段话非常重要，我经常看到由于混淆了实体和Actor的关系而导致画出的领域类图不准确或职责分配不准确。
大家可能还注意到，我们这里没有给出每个实体的属性。
其实，在领域分析阶段，实体的属性并不重要，重要的是找出实体的操作。
6.绘制实现类图
以上这几步，就是分析的过程。
而下面的步骤就是设计了。
设计没有分析那么好描述，因为分析是“客户面”，它只关心系统本身的功能和业务，而不关心任何和计算机有关的东西。
但是，设计和平台、语言、开发模型等内容关系紧密，因而很难找出一个一致的过程。
但是，一般在设计过程中实现类图是要绘制的。
实现类图和领域类图不一样，它描述的是真正系统的静态结构，是和最后的代码完全一致的。
因此，它和平台关系密切，必须准确给出系统中的实体类、控制类、界面类、接口等元素以及其中的关系。
因此，实现类图是很复杂的，而且是平台技术有关的。
所以，我在这里不可能给出一个准确的实现类图，不过为了描述，我还是给出一个简化了的实现类图，当然，它是不准确的，而只是从形式上给出实现类图的样子。
我们假设这个系统建构于.NET3.5平台上，并且使用ASP.NETMVC作为表示层，整体使用三层架构。
那么，用户模块体系的实现类图大体是这样子（不准确）：
7.绘制序列图
有了静态结构，我们还要给出动态结构，这样，才能看清系统间的类是如何交互的，从而有效帮助程序员进行编码工作。
上图给出的是用户登录的序列图。
首先注册会员作为Actor，调用UserController的Login方法启动序列，然后序列按图示步骤执行。
其中UserServices作为业务组件，首先调用数据访问组件的GetByName确定用户是否存在，如果存在，再调用GetByNameAndPassword确定输入密码是否是此用户的密码。
从而完成业务功能。
要注意，序列图在实际中是很多的，几乎每个类方法都配有相应的序列图。
8.后面的步骤
在完成了上面的过程后，就可以进行编码、调试、测试等工作了。
但这些已经超出了本文讨论的范围。
总结
本文简要给出了使用UML进行OOA&D的过程。
当然，由于示例较小，而且本人水平有限，所以给出的相关内容可能不是很准确。
而且软件分析设计本来就不是一个固定模式的过程，随着系统的不同整个过程会有变化。
本文只是想起到一个抛砖引玉的作用，让朋友们大致了解UML的使用流程。
至于实际的分析设计，还需要深入的学习和实践的积累。
升级会员 