本科实验报告

课程名称：     系统分析与设计          

实验项目：   《网上书店系统》实验     

实验地点：      逸夫楼404                       

专业班级：   软件1013班           学号：2010004744         

学生姓名：   荆婉                          

指导教师：   雷红                          

20##年   11月   17日

目   录

1.      实验准备：熟悉UML建模环境

2.      实验一 用例图

3.      实验二 类图

4.      实验三 顺序图及通信图

5.      实验四 活动图、状态图、组件图及部署图

实验一  用例图

一、        实验目的

初步掌握UML用例图的创建方法及其用例的描述。

二、实验要求

1．结合工具StartUML，熟悉UML用例图的模型元素。

2．使用StartUML工具建模网上书店系统的用例图。

三、实验主要设备：台式或笔记本计算机

四、实验内容：

根据下面给出的网上书店问题陈述，分析该系统总体需求，建模网上书店系统的用例图并提供一个主要用例的事件流文档。

网上书店陈述：

书店经理：我们原本是一个传统的实体书店，顾客要买书都是亲自到书店里来的，这样挺不方便。面且随着书店销售图书种类和数量的增加以及顾客的增长，尤其是大量顾客到书店选购图书，使得书店场地不足，工作人员也很忙碌。其实，还有一点就是，有不少人进入书店后并不买书，只是查找一些资料。有的甚至会在这呆上很长的时间直到把书免费看完。这种行为，工作人员一般是不阻止的，结果最后这些被看过的书会因为有阅读过的痕迹而影响销售。而且现在电子商务已经发展起来了，所以我们想到借助网络，让顾客通过网上书店购买图书。这样我们书店可以省掉大量的场地维护和工作人员成本支出，同时计算机可以方便的检索图书信息，让顾客可以足不出户以更优惠的价格买到需要的书。

系统分析员：能谈谈您对网上书店的要求吗?

书店经理：网上书店要能实现对外和对内的功能，对外是顾客能在网上书店订购图书，提交订单。对内，书店工作人员能够通过网上书店及时的看到这些订单，并进行处理。为了把书送到顾客手里，我们已经联系了快递公司，初步达成协议，由他们往返场客和书店之间把图书送到顾客手里。书店管理员受理订单后，就会通知快递公司送货。当然，书店的图书上架和下架也应该由网上书店完成了。

工作人员甲：实体店中，图书是按照不同种类放置的，方便顾客挑选。网上书店的图书也应该能够按照这种模式分类显示。这样，图书的信息和种类要由网上书店设置和管理。已有种类的新书或新种类的图书上架，网上书店能够保存这些信息。如果信息输入错误，能够进行修改。

工作人员乙：另外书店会搞一些促销，推出一些特价图书。以前这些特价书的信息，都是我们根据促销活动整理出来，贴在书店的醒目位置。促销活动过后，特价图书会恢复原来的价格。希望网上书店也能够管理这些特价图书。

系统分析员：能谈谈平时买书的经过吗?

顾客甲：一般都是先在书店里看看图书的简要介绍，或者先找找看有没有自己需要的书，有时是没有目标的寻找，有时直奔一类图书而去。找到我想买的书或者觉得看的书不错，就会去柜台结帐。

工作人员丙：不过有时在结帐的时候，顾客会突然改变主意，不买一些书或者又回去挑选图书了。

顾客甲：有时好像是这样的。要是网上书店在结帐前能方便管理我所选购的图书就好了，这样通过计算机直接操作，就不用跑来跑去了。

系统分析员：可以使用虚拟的购物车。

工作人员丙：对，这样在用户确认购买前可自行管理选购的图书，决定要不要购买还有的购买的数量。

系统分析员：顾客先使用虚拟的购物车选购管理图书，然后提交订单给书店处理，是这样吧。

书店经理：没错，就这样办。另外最好顾客能够留下自己的信息，方便以后的购买。

顾客：你们可以实行会员制啊。就像我们在网上逛论坛一样，会员才能发言，普通游客只能看。这样我们平时就在网上书店查查资料什么的，只在购买图书的时候才使用会员身份。

书店经理：嗯，这样不仅可以保留你们的信息，也可以保留购买记录。

系统分析员：会员提交购买订单后，书店打算如何收取或者说用户怎么付款?

书店经理：我们可以接受货到付款，顾客也可以使用网上银行、汇款等方式付款。

顾客：这样我们就方便多了。对了那是不是付款前，我还多了一次“反悔”的机会啊。

书店经理：在我们书店没有受理订单之前，你们可以取消交易。不过受理后就不行了。

……

通过几次这样的访谈（限于篇幅，在此并未列出所有访谈内容），可以获得网上书店的需求信息，确定系统范围。网上书店是实现对实体书店内部图书商品和顾客购买图书的综合管理系统。

1.　用例图：

此处由学生填写

                           

                    

2.确认订单用例事件流

1.用例确认订单的事件流

1.1前置条件

   在用例确认订单开始之前，用例登录该系统以及用例使用虚拟购物车必须完成。

1.2后置条件

如果确认订单的事件成功后，就可以提交订单或者若顾客改变主意，不想购买图书，则交给虚拟购物车进行管理。

1.3扩充点

无

1.4事件流

1.4.1基流

   登陆系统，顾客先以普通顾客的身份查找所需要购买的图书并添加到购物车，此时用例确认订单开始，系统提示顾客所想要选择的动作：购买、不购买、稍后再买。

   如果所选的活动是购买，执行分支流S-1：购买所需要的图书。

   如果所选的活动是不买，执行分支流S-2：不够买该书但保留                    其信息。

   如果所选的活动是稍后购买，执行分支流S-3：稍后再购买该书，保留其信息等待购买。

1.4.2分支流

S-1购买

   系统提示是否购买该书，顾客选中购买，并选中要购买的书名及购买的数量（E-1或E-2)，系统显示信息可以购买，并建立购买连接。

S-2不购买

   系统提示是否购买该书，顾客选中不购买，此时系统将保存该书的记录并不作任何处理。

S-3稍后购买

   系统提示是否购买该书，顾客选中稍后购买，此时系统将保留该书信息并等待顾客购买。

1.4.3替代流

E-1如果所选的书该书店没有存货，系统提示该书缺货无法购买，顾客可选择其他书进行购买；；

E-2如果所选的书数量超过该书店的所拥有的数量，则系统提示书的数量过多无法购买，并提示可选择少量进行购买。

五、分析与讨论

1.建模用例图的步骤、方法？

1.寻找参与者寻找参与者

所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。

2.确定用例

   找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。

3.描述用例规约

   应该避免这样一种误解——认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述——用例规约所组成的.

4.检查用例模型

   用例模型完成之后，可以对用例模型进行检查，看看是否有遗漏或错误之处。

2.如何识别系统的参与者？

?    谁是系统的主要用户

?    谁向系统提供信息

?    谁改变系统的数据

?    谁从系统获取信息

?    谁需要系统的支持以完成日常工作任务

?    谁负责日常维护、管理并保证系统正常运行

?    系统需要操纵那些硬设备

?    系统需要和那些外部系统交互

?    谁（或什么）对系统运行产生的结果（值）感兴趣

?    时间、气温等内部外部条件

?    ……

3.应该如何划分用例，应注意哪些问题？
　　1、使用功能点划分，细化每个功能点，到这个功能点不能再拆分。
　　2、所要测试模快对该系统的整体影响。看其重要性。
　　3、最好在用例编写前，项目的测试工程师可以讨论出一个适合项目的统一测试粒度。

应注意：

    1、测试粒度不宜过细，测试用例分解的测试粒度过细会给测试工程师带来成倍的额外工作量，对于项目管理来讲，这样是不合算的。
　　2、测试粒度不宜过粗，这是因为如果一个测试用例，里面包含了太多验证点。比如在写取钱的用例时，要检查余额查询，用户最大额度查询类似的本可以单独一个用例的东西都硬拼到了一起，那么用例的执行进度和项目的进度肯定不能划等号。简单说就是有的用例简单有的用例复杂，所以有的也许要验证半天，有的只需要10分钟。这样的话，文章开头的等式就当然不相等了。
　　粒度过粗还有个麻烦就是，发现很多bug都对应着一个用例。这样给缺陷管理和统计起来也带来麻烦。在项目后期的报告中不能清晰的统计缺陷。

4.．心得

我认为，用例就是功能，用例图就是对功能的图示描述；也就是功能模块的表示。同时用例图是对用户的需求进行描述，所以，从用例图中能看出现实的功能需求，貌似是对现实世界想要完成某件事情的物理结构进行画图表示。用例图的粒度是第一次听说，经过老师的讲解，感觉粒度就是个数的意思，搞不懂为什么翻译为粒度（granularity）。也就是一个软件划分为多少个模块。这就涉及到模块的耦合和内聚了。模块太少不能把用户的需求功能描述清楚，太多了，又过于冗杂，同样不能把功能描述清楚。
    用例图是开发一个软件时用到的第一个图，所以，UML用例图画好了，对后面的开发至关重要。用例图就是对现实需求的第一步抽象，把功能用图表述出来。在画用例图的时候就应该把用各个用例之间的关系表达清楚。

实验二  类图

一、        实验目的

了解类图的基本用法；初步掌握UML类图的创建及其方法。

二、实验要求

1、结合工具StartUML，熟悉UML类图的模型元素。

2、建模网上书店类图。

三、实验主要设备：台式或笔记本计算机

四、实验内容：

创建类图的步骤如下：

（1）使用名词识别法识别类。

（2）建模类与类之间的关系。

（3）为类图中的关联关系添加合适的角色名。

（4）为已被封装到类中的独立功能建模类。

（5）为类图中的类添加必要的特性和操作。

（6）迭代并细化该模型

1.识别类：（删除以下样式  ， 填写）

顾客（普通顾客，会员），书店工作人员，虚拟购物车，图书（特价图书）

2. 定义类：（删除以下样式 ，  填写）

图 2.1 定义类

图2.2完善后的类图

五、分析与讨论

1. 如何使用文本分析技术从问题陈述中识别对象和类？

识别对象：

   识别问题中的实体，实体的描述用名词，名词短语，，名词性代词的形式出现。

识别类：

  分别找出：

     边界类：边界类处理系统环境与系统内部之间的通信，边界类为用户或另一个系统（即参与者）提供了接口。

     实体类 ：实体类是模拟必须被存储的信息和其关联行为的类。

     控制类 ：控制类是用来为特定于一个或多个用例的控制行为建模的类。

     参数类 ：参数类又被称为模板类（Template Classes），模板类定义了类族。

2. 心得

通过本次实验，我对类图有了新的认识，类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图(Class diagram)是最常用的UML图，显示出类、接口以及它们之间的静态结构和关系，它用于描述系统的结构化设计。类的 UML 表示是一个长方形，垂直地分为三个区。

画类图时，首先要从问题中出所有的名词，再从中选择出可以作为类的名词作为候选类，然后找分别边界类、实体类和控制类初步定出类的概念层，然后找出这些类的属性和操作最终确定出分析层，进而完善成完整的类图。

         实验三  顺序图及通信图

一、        实验目的

初步掌握UML顺序图的建模及其思想。

二、实验要求

1、结合工具StartUML和Rose，熟悉UML顺序图的模型元素。

2、建模网上书店交互图。

三、实验主要设备：台式或笔记本计算机

四、实验内容：

1. 给出网上书店的一个用例的顺序图，例如，书店管理员登录顺序图、会员添加图书到购物车顺序图或其他用例的顺序图。

                              （顺序图）

2. 把以上顺序图转换为通信图。

                            （通信图）

五、分析与讨论

1. 如何从用例图建模顺序图？

 从用例图中选择一个具体的用例，对这个用例的每个操作用顺序图具体的划分出来

2. 顺序图和通信图的比较？

顺序图和通信图都属于交互图。
这两种图之间的区别在于：顺序图基于时间，按时间顺序显示出现的任务；而通信图显示任务和信息(对象)的交互方式。在通信中，时间以编码形式显示，很难选取。
虽然存在这些根本区别，但这两类图有相同之处：都用于显示对象和用户如何交互以执行任务。

3. 心得

通过本次试实验，我知道了用例图和通信图以不同的方式表达了类似的信息，顺序图强调消息的时间顺序，适合与描述实时系统和复杂的脚本；通信图则描述了对象之间的关系。这两个图用于为系统动态方面的建模，同时，通过对StarUML软件的学习让我对这点理解更加深刻。

这两种图之间的区别在于：顺序图基于时间，按时间顺序显示出现的任务；而通信图显示任务和信息(对象)的交互方式。在通信中，时间以编码形式显示，很难选取。虽然存在这些根本区别，但这两类图有相同之处：都用于显示对象和用户如何交互以执行任务。

     另外，我认为，首先根据自己的喜好和实际的表现需要来选择顺序图或通信图。不过由于它们在语义上是等价的，因此可以绘制出一种，再通过建模工具来自动转换成另一种图，分析模型中的交互图彻重于分析类的职责分配和交互流程，而设计模型中的交互图则彻重于设计类的引入和实际方法的调用与流程控制，先确定参与交互的对象、对象之间的关系（通信图），然后确定对象间的消息交互流程（用同步调用、异步消息、返回消息表示），并利用交互片断（顺序图）或迭代标记及监护条件来表示循环和分支结构

 

     实验四 活动图、状态图及部署图

一、实验目的

1. 了解活动图、状态图及部署图的基本用法；

2.  初步掌握活动图、状态图及部署图建模方法。

二、实验要求

1、结合工具StartUML，熟悉UML活动图、状态图及部署图的基本模型元素。

2、建模网上书店的活动图、状态图及部署图。

三、实验主要设备：台式或笔记本计算机

四、实验内容：

活动图：

状态图：

部署图：

五、分析与讨论

1. 什么情况下适合引入状态图进行建模？

   但需要描述一个特定对象的所有可能的状态，以及引起状态跃迁的事件时以及用来描述整个系统、子系统或类的动态方面时需要用到状态机图，状态机图用来模拟系统的动态方面。

2. 心得

    通过此次试验，我了解了活动图、状态图、部署图的基本用法并初步掌握活动图、状态图、部署图建模方法。活动图表示在处理某个活动时，两个或者更多类对象之间的过程控制流。活动图可用于在业务单元的级别上对更高级别的业务过程进行建模，或者对低级别的内部类操作进行建模。根据我的经验，活动图最适合用于对较高级别的过程建模，比如公司当前在如何运作业务，或者业务如何运作等；状态图表示某个类所处的不同状态和该类的状态转换信息。有人可能会争论说每个类都有状态，但不是每个类都应该有一个状态图；部署图表示该软件系统如何部署到硬件环境中。它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信。因为部署图是对物理运行情况进行建模，系统的生产人员就可以很好地利用这种图。

    并且，我知道了活动图主要是一个流图，描述了从活动到活动的流；状态机图用于描述一个对象在其生存期间的动态行为，表现对象响应事件所经历的状态序列以及伴随的动作；部署图描述了节点和运行其上的组建的配置它是用来为面向对象的物理实现建模的两种图之一。

第二篇：Java系统分析实验报告UML

本科实验报告

课程名称：     系统分析与设计          

实验项目：   《网上书店系统》实验     

实验地点：                            

专业班级：              学号：         

学生姓名：                             

指导教师：                             

20##年   11月   17日

目   录

1.      实验准备：熟悉UML建模环境

2.      实验一 用例图

3.      实验二 类图

4.      实验三 顺序图及通信图

5.      实验四 活动图、状态图、组件图及部署图

实验一  用例图

一、        实验目的

初步掌握UML用例图的创建方法及其用例的描述。

二、实验要求

1．结合工具StartUML，熟悉UML用例图的模型元素。

2．使用StartUML工具建模网上书店系统的用例图。

三、实验主要设备：台式或笔记本计算机

四、实验内容：

根据下面给出的网上书店问题陈述，分析该系统总体需求，建模网上书店系统的用例图并提供一个主要用例的事件流文档。

网上书店陈述：

书店经理：我们原本是一个传统的实体书店，顾客要买书都是亲自到书店里来的，这样挺不方便。面且随着书店销售图书种类和数量的增加以及顾客的增长，尤其是大量顾客到书店选购图书，使得书店场地不足，工作人员也很忙碌。其实，还有一点就是，有不少人进入书店后并不买书，只是查找一些资料。有的甚至会在这呆上很长的时间直到把书免费看完。这种行为，工作人员一般是不阻止的，结果最后这些被看过的书会因为有阅读过的痕迹而影响销售。而且现在电子商务已经发展起来了，所以我们想到借助网络，让顾客通过网上书店购买图书。这样我们书店可以省掉大量的场地维护和工作人员成本支出，同时计算机可以方便的检索图书信息，让顾客可以足不出户以更优惠的价格买到需要的书。

系统分析员：能谈谈您对网上书店的要求吗?

书店经理：网上书店要能实现对外和对内的功能，对外是顾客能在网上书店订购图书，提交订单。对内，书店工作人员能够通过网上书店及时的看到这些订单，并进行处理。为了把书送到顾客手里，我们已经联系了快递公司，初步达成协议，由他们往返场客和书店之间把图书送到顾客手里。书店管理员受理订单后，就会通知快递公司送货。当然，书店的图书上架和下架也应该由网上书店完成了。

工作人员甲：实体店中，图书是按照不同种类放置的，方便顾客挑选。网上书店的图书也应该能够按照这种模式分类显示。这样，图书的信息和种类要由网上书店设置和管理。已有种类的新书或新种类的图书上架，网上书店能够保存这些信息。如果信息输入错误，能够进行修改。

工作人员乙：另外书店会搞一些促销，推出一些特价图书。以前这些特价书的信息，都是我们根据促销活动整理出来，贴在书店的醒目位置。促销活动过后，特价图书会恢复原来的价格。希望网上书店也能够管理这些特价图书。

系统分析员：能谈谈平时买书的经过吗?

顾客甲：一般都是先在书店里看看图书的简要介绍，或者先找找看有没有自己需要的书，有时是没有目标的寻找，有时直奔一类图书而去。找到我想买的书或者觉得看的书不错，就会去柜台结帐。

工作人员丙：不过有时在结帐的时候，顾客会突然改变主意，不买一些书或者又回去挑选图书了。

顾客甲：有时好像是这样的。要是网上书店在结帐前能方便管理我所选购的图书就好了，这样通过计算机直接操作，就不用跑来跑去了。

系统分析员：可以使用虚拟的购物车。

工作人员丙：对，这样在用户确认购买前可自行管理选购的图书，决定要不要购买还有的购买的数量。

系统分析员：顾客先使用虚拟的购物车选购管理图书，然后提交订单给书店处理，是这样吧。

书店经理：没错，就这样办。另外最好顾客能够留下自己的信息，方便以后的购买。

顾客：你们可以实行会员制啊。就像我们在网上逛论坛一样，会员才能发言，普通游客只能看。这样我们平时就在网上书店查查资料什么的，只在购买图书的时候才使用会员身份。

书店经理：嗯，这样不仅可以保留你们的信息，也可以保留购买记录。

系统分析员：会员提交购买订单后，书店打算如何收取或者说用户怎么付款?

书店经理：我们可以接受货到付款，顾客也可以使用网上银行、汇款等方式付款。

顾客：这样我们就方便多了。对了那是不是付款前，我还多了一次“反悔”的机会啊。

书店经理：在我们书店没有受理订单之前，你们可以取消交易。不过受理后就不行了。

……

通过几次这样的访谈（限于篇幅，在此并未列出所有访谈内容），可以获得网上书店的需求信息，确定系统范围。网上书店是实现对实体书店内部图书商品和顾客购买图书的综合管理系统。

1.　用例图：

此处由学生填写

                           

                    

2.确认订单用例事件流

1.用例确认订单的事件流

1.1前置条件

   在用例确认订单开始之前，用例登录该系统以及用例使用虚拟购物车必须完成。

1.2后置条件

如果确认订单的事件成功后，就可以提交订单或者若顾客改变主意，不想购买图书，则交给虚拟购物车进行管理。

1.3扩充点

无

1.4事件流

1.4.1基流

   登陆系统，顾客先以普通顾客的身份查找所需要购买的图书并添加到购物车，此时用例确认订单开始，系统提示顾客所想要选择的动作：购买、不购买、稍后再买。

   如果所选的活动是购买，执行分支流S-1：购买所需要的图书。

   如果所选的活动是不买，执行分支流S-2：不够买该书但保留                    其信息。

   如果所选的活动是稍后购买，执行分支流S-3：稍后再购买该书，保留其信息等待购买。

1.4.2分支流

S-1购买

   系统提示是否购买该书，顾客选中购买，并选中要购买的书名及购买的数量（E-1或E-2)，系统显示信息可以购买，并建立购买连接。

S-2不购买

   系统提示是否购买该书，顾客选中不购买，此时系统将保存该书的记录并不作任何处理。

S-3稍后购买

   系统提示是否购买该书，顾客选中稍后购买，此时系统将保留该书信息并等待顾客购买。

1.4.3替代流

E-1如果所选的书该书店没有存货，系统提示该书缺货无法购买，顾客可选择其他书进行购买；；

E-2如果所选的书数量超过该书店的所拥有的数量，则系统提示书的数量过多无法购买，并提示可选择少量进行购买。

五、分析与讨论

1.建模用例图的步骤、方法？

1.寻找参与者寻找参与者

所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。

2.确定用例

   找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。

3.描述用例规约

   应该避免这样一种误解——认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述——用例规约所组成的.

4.检查用例模型

   用例模型完成之后，可以对用例模型进行检查，看看是否有遗漏或错误之处。

2.如何识别系统的参与者？

?    谁是系统的主要用户

?    谁向系统提供信息

?    谁改变系统的数据

?    谁从系统获取信息

?    谁需要系统的支持以完成日常工作任务

?    谁负责日常维护、管理并保证系统正常运行

?    系统需要操纵那些硬设备

?    系统需要和那些外部系统交互

?    谁（或什么）对系统运行产生的结果（值）感兴趣

?    时间、气温等内部外部条件

?    ……

3.应该如何划分用例，应注意哪些问题？
　　1、使用功能点划分，细化每个功能点，到这个功能点不能再拆分。
　　2、所要测试模快对该系统的整体影响。看其重要性。
　　3、最好在用例编写前，项目的测试工程师可以讨论出一个适合项目的统一测试粒度。

应注意：

    1、测试粒度不宜过细，测试用例分解的测试粒度过细会给测试工程师带来成倍的额外工作量，对于项目管理来讲，这样是不合算的。
　　2、测试粒度不宜过粗，这是因为如果一个测试用例，里面包含了太多验证点。比如在写取钱的用例时，要检查余额查询，用户最大额度查询类似的本可以单独一个用例的东西都硬拼到了一起，那么用例的执行进度和项目的进度肯定不能划等号。简单说就是有的用例简单有的用例复杂，所以有的也许要验证半天，有的只需要10分钟。这样的话，文章开头的等式就当然不相等了。
　　粒度过粗还有个麻烦就是，发现很多bug都对应着一个用例。这样给缺陷管理和统计起来也带来麻烦。在项目后期的报告中不能清晰的统计缺陷。

4.．心得

我认为，用例就是功能，用例图就是对功能的图示描述；也就是功能模块的表示。同时用例图是对用户的需求进行描述，所以，从用例图中能看出现实的功能需求，貌似是对现实世界想要完成某件事情的物理结构进行画图表示。用例图的粒度是第一次听说，经过老师的讲解，感觉粒度就是个数的意思，搞不懂为什么翻译为粒度（granularity）。也就是一个软件划分为多少个模块。这就涉及到模块的耦合和内聚了。模块太少不能把用户的需求功能描述清楚，太多了，又过于冗杂，同样不能把功能描述清楚。
    用例图是开发一个软件时用到的第一个图，所以，UML用例图画好了，对后面的开发至关重要。用例图就是对现实需求的第一步抽象，把功能用图表述出来。在画用例图的时候就应该把用各个用例之间的关系表达清楚。

实验二  类图

一、        实验目的

了解类图的基本用法；初步掌握UML类图的创建及其方法。

二、实验要求

1、结合工具StartUML，熟悉UML类图的模型元素。

2、建模网上书店类图。

三、实验主要设备：台式或笔记本计算机

四、实验内容：

创建类图的步骤如下：

（1）使用名词识别法识别类。

（2）建模类与类之间的关系。

（3）为类图中的关联关系添加合适的角色名。

（4）为已被封装到类中的独立功能建模类。

（5）为类图中的类添加必要的特性和操作。

（6）迭代并细化该模型

1.识别类：（删除以下样式  ， 填写）

顾客（普通顾客，会员），书店工作人员，虚拟购物车，图书（特价图书）

2. 定义类：（删除以下样式 ，  填写）

图 2.1 定义类

图2.2完善后的类图

五、分析与讨论

1. 如何使用文本分析技术从问题陈述中识别对象和类？

识别对象：

   识别问题中的实体，实体的描述用名词，名词短语，，名词性代词的形式出现。

识别类：

  分别找出：

     边界类：边界类处理系统环境与系统内部之间的通信，边界类为用户或另一个系统（即参与者）提供了接口。

     实体类 ：实体类是模拟必须被存储的信息和其关联行为的类。

     控制类 ：控制类是用来为特定于一个或多个用例的控制行为建模的类。

     参数类 ：参数类又被称为模板类（Template Classes），模板类定义了类族。

2. 心得

通过本次实验，我对类图有了新的认识，类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图(Class diagram)是最常用的UML图，显示出类、接口以及它们之间的静态结构和关系，它用于描述系统的结构化设计。类的 UML 表示是一个长方形，垂直地分为三个区。

画类图时，首先要从问题中出所有的名词，再从中选择出可以作为类的名词作为候选类，然后找分别边界类、实体类和控制类初步定出类的概念层，然后找出这些类的属性和操作最终确定出分析层，进而完善成完整的类图。

         实验三  顺序图及通信图

一、        实验目的

初步掌握UML顺序图的建模及其思想。

二、实验要求

1、结合工具StartUML和Rose，熟悉UML顺序图的模型元素。

2、建模网上书店交互图。

三、实验主要设备：台式或笔记本计算机

四、实验内容：

1. 给出网上书店的一个用例的顺序图，例如，书店管理员登录顺序图、会员添加图书到购物车顺序图或其他用例的顺序图。

                              （顺序图）

2. 把以上顺序图转换为通信图。

                            （通信图）

五、分析与讨论

1. 如何从用例图建模顺序图？

 从用例图中选择一个具体的用例，对这个用例的每个操作用顺序图具体的划分出来

2. 顺序图和通信图的比较？

顺序图和通信图都属于交互图。
这两种图之间的区别在于：顺序图基于时间，按时间顺序显示出现的任务；而通信图显示任务和信息(对象)的交互方式。在通信中，时间以编码形式显示，很难选取。
虽然存在这些根本区别，但这两类图有相同之处：都用于显示对象和用户如何交互以执行任务。

3. 心得

通过本次试实验，我知道了用例图和通信图以不同的方式表达了类似的信息，顺序图强调消息的时间顺序，适合与描述实时系统和复杂的脚本；通信图则描述了对象之间的关系。这两个图用于为系统动态方面的建模，同时，通过对StarUML软件的学习让我对这点理解更加深刻。

这两种图之间的区别在于：顺序图基于时间，按时间顺序显示出现的任务；而通信图显示任务和信息(对象)的交互方式。在通信中，时间以编码形式显示，很难选取。虽然存在这些根本区别，但这两类图有相同之处：都用于显示对象和用户如何交互以执行任务。

     另外，我认为，首先根据自己的喜好和实际的表现需要来选择顺序图或通信图。不过由于它们在语义上是等价的，因此可以绘制出一种，再通过建模工具来自动转换成另一种图，分析模型中的交互图彻重于分析类的职责分配和交互流程，而设计模型中的交互图则彻重于设计类的引入和实际方法的调用与流程控制，先确定参与交互的对象、对象之间的关系（通信图），然后确定对象间的消息交互流程（用同步调用、异步消息、返回消息表示），并利用交互片断（顺序图）或迭代标记及监护条件来表示循环和分支结构

 

     实验四 活动图、状态图及部署图

一、实验目的

1. 了解活动图、状态图及部署图的基本用法；

2.  初步掌握活动图、状态图及部署图建模方法。

二、实验要求

1、结合工具StartUML，熟悉UML活动图、状态图及部署图的基本模型元素。

2、建模网上书店的活动图、状态图及部署图。

三、实验主要设备：台式或笔记本计算机

四、实验内容：

活动图：

状态图：

部署图：

五、分析与讨论

1. 什么情况下适合引入状态图进行建模？

   但需要描述一个特定对象的所有可能的状态，以及引起状态跃迁的事件时以及用来描述整个系统、子系统或类的动态方面时需要用到状态机图，状态机图用来模拟系统的动态方面。

2. 心得

    通过此次试验，我了解了活动图、状态图、部署图的基本用法并初步掌握活动图、状态图、部署图建模方法。活动图表示在处理某个活动时，两个或者更多类对象之间的过程控制流。活动图可用于在业务单元的级别上对更高级别的业务过程进行建模，或者对低级别的内部类操作进行建模。根据我的经验，活动图最适合用于对较高级别的过程建模，比如公司当前在如何运作业务，或者业务如何运作等；状态图表示某个类所处的不同状态和该类的状态转换信息。有人可能会争论说每个类都有状态，但不是每个类都应该有一个状态图；部署图表示该软件系统如何部署到硬件环境中。它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信。因为部署图是对物理运行情况进行建模，系统的生产人员就可以很好地利用这种图。

    并且，我知道了活动图主要是一个流图，描述了从活动到活动的流；状态机图用于描述一个对象在其生存期间的动态行为，表现对象响应事件所经历的状态序列以及伴随的动作；部署图描述了节点和运行其上的组建的配置它是用来为面向对象的物理实现建模的两种图之一。