《中南大学,软件体系结构实验报告.docx》由会员分享，可在线阅读，更多相关《中南大学,软件体系结构实验报告.docx（25页珍藏版）》请在三一文库上搜索。
1、中南大学软件体系结构实验报告题目系统的用例模型 +类模型 +状态建模指导老师李祖德学生姓名孙毅学生学号0906140106学院信息科学与工程学院专业班级信安1401 班完成时间2016年11月30日目录实验一系统的用例模型0一、实验目的0二、实验器材0三、实验内容0四、实验步骤0五、实验心得体会3实验二系统的类模型5一、实验目的5二、实验器材5三、实验内容5四、实验步骤5五、实验心得体会16实验三系统的状态建模17一、实验目的17二、实验器材17三、实验内容17四、实验步骤17五、 实验心得体会21实验一系统的用例模型实验名称：系统的用例模型实验类型 :设计性实验一、实验目的1熟悉用例图的基本
2、功能和使用方法。2锻炼结合给定题目，进行有效需求分析的能力。3掌握如何使用建模工具绘制用例图的方法。二、实验器材1计算机一台。2 UML 建模工具， StarUML 。三、实验内容在理解用例图的基本功能和使用方法的基础上，得到用例模型后，应针对每个用例进行业务分析，或 StarUML 工具软件绘制系统的用例图。下文以结合具体问题， 完成对系统的需求建模，说明其具体的业务流程。用 Rational RoseRational Rose 为例讲解基本步骤。四、实验步骤(1) 在图中的工具栏选取 Actor 图标，在右边的图中添加一个 Actor ，并输入名称 :administrator, 如图 1
3、.1 所示。图 1.1(2) 在左边的工具栏中，选取用例的图标，在右边的图中画出一个用例，并输入用例的名称：login ,如图 1.2 所示。图 1.2(3) 按照 (2), 在右边的图中画出另外两个用例，并输入用例的名称：search， delete。如图 1.3所示。图 1.3(4) 在绘出了用例后，接下来的是绘制参与者与用例实现，如图1.4 所示。图 1.4(5) 根据步骤 (4)，同时完成如图 1.5 和图 1.6。此时，删除读者用例图就到此完成。其系统查询读者信息等其他的功能会在时序图和活动图中描绘。图 1.5图 1.6(6) 根据分析情况，进一步添加或细化用例图。五、实验心得体会由
4、于这是第一次做这样的实验，所以呢，首先所花的时间在软件的下载与安装上，尤其是在在控制面板启动FLEXlm License Manager 的服务一个环节上花费了一些时间和心思，开始是在控制面板上找不到FLEXlm License Manager这一项，后来将安装指导的“flexlm.cpl拷贝到 system32 目录下”改为了“flexlm.cpl拷贝到 sysWOW64目录下“之后并进行相应的设置才成功启动了这项服务。至于这实验一，由于第一次接触这样的实验，对软件也不熟悉，所以就很死板的跟着老师给的实验指导书上说的做，所以就没有花太多心思去思考，到做到后来，我意识到，只是这样很机械的跟着老
5、师的步骤做的话不会有太多的收获，所以，我就搜索了一些相关与rational rose和 uml 的资料。在资料上我了解解到，用例模型用于需求分析阶段，它描述了待开发系统的功能需求，并驱动了需求分析之后各阶段的开发工作。用例图是 uml 中用来对系统的动态方面进行建模的 7 种图之一。 用例图描述了用例、 参与者以及它们之间的关系。用例图从用户角度描述系统功能，并指出各功能的操作者。通过本次实验，我熟悉rationalrose 建模环境，更加清楚的了解了用例图的语义和功能，如何清晰明了的识别参与者、 用例，学会了如何使用事件流描述用例。同时掌握了用例间的类属关系、include关系和 exten
6、d 关系的语义、功能和应用。最后通过本次实验学习了如何使用用例图为系统的上下文以及系统的需求建模。实验二系统的类模型实验名称：系统的类模型实验类型 :设计性实验一、实验目的1理解类的2掌握如何从需求分析中抽象出类的方法。3掌握在Rational Rose 或 StarUML 中绘制类的操作方法。二、实验器材1计算机一台。2 Rational Rose 或 StarUML 工具软件。三、实验内容完成实验一后， 对给定题目的系统的需求的初步分析，得出系统的用例图，通过对用例的业务流程的分析，我们可以初步了解系统的业务处理流程。本实验需要对系统进行静态建模，这就需要从系统的用例图去寻找和发现类。用R
7、ational Rose 或 StarUML 工具软件绘制系统的类图。下文以StarUML 为例讲解基本步骤。四、实验步骤(1) 打开Rose 中的逻辑视图（Logical View），选择分析模型（analysis model ）目录。并在其下创建一个子目录并命名为：“图书馆业务功能”, 如图2.1 所示。(2) 用鼠标右击“图书馆业务功能”在弹出来的菜单中选择“建类图 , 如图 2.2 所示。New Class diagram”项，创图 2.1(3) 双击新建的类图，并点右边控件集中选中的类的图标，并用鼠标在图中分别拖出一个类图，并命名为 Book ，如图，所示。图 2.2（4）接下来的一
8、步为设置类的属性，在新的类中双击该类，在打开属性面板中，可以看到在此可以设置类的属性和方法等其他的信息，图2.3 所示；图 2.3(5) 后点击 Attributes 这个栏目，此栏目为设置类的属性的选项，在图中间的单击右键，可以看到有一个“ Insert”的选项，选中这个选项，图2.4 所示；图 2.4(6) 后在出现的对话框中输入相关信息如图2.5 所示；图 2.5(7) 如书本的 ISBN 号，在 Type 这个方框内输入此属性的类型值，同时可以看到一栏可以设置此属性的访问权限，一般这些属性都设置Private 这个权限，如图2.6 所示；图 2.6(8) 这个类的其他属性也可以按照以上
9、的做法设置，最后得到的结果是图2.7 所示。图 2.7（ 9）设置好类的属性，现在来设置类的方法（也是操作），双击类后在弹出的菜单上选operations 这个选项，可以看到图2.8 所示；图 2.8（ 10）在图中的空白地方，单击右键，在弹出的菜单中选insert这个选项，也就只有这个选项可用，接着输入方法名，同时可以设置该方法的返回类型，见图2.9,也可以在Documentations的方框内填写一些相关的方法说明，设置好该方法的访问权限，见图2.10；图 2.9图 2.10（ 11）类的其他方法也可以按上面来设置好，最后，得到该类的其他方法见类2.11。图 2.11（ 12）至此，类的方
10、法和属性都设置好了，如图2.12 所示。（ 13）按照上面的步骤设置好所有类的属性和方法。（ 14）为各个类添加关系，由关联、泛化、依赖等关系来静态描述业务。五、实验心得体会有了实验一的过程，我对软件的使用有了一定的了解，于是在实验前查阅资料，从资料上得知：类模型是面向对象分析的核心，用类图来描述。 类图主要描述系统中类、类与类之间的关系， 首先标识类和关联，因为它们影响到整体结构和解决方法，其次是增加属性，进一步描述类和关联，总之这一次实验加强了对类模型的理解，对软件UML 的使用更加的熟练了，为以后自己构建模型奠定了基础。类图是面向对象系统建模最常用的图，描述了类图、 接口集、协作以及它们
11、之间的关系。类图描述了系统的静态设计视，该视主要体现系统的功能需求，即系统应该提供给用户的服务。通过本次实验， 加深了我对类图语义的理解和功能的应用，掌握了类之间的联系，关联、依赖、聚合等，同时基本掌握了在rational rose 中绘制类的关联、依赖、泛化关系。从以上可以看出，我在接触新鲜事物的时候，对不明白不了解的东西有着一定的好奇心的，所以我就会去学习去查阅资料，在这个过程中，不知不觉的，我学到的不仅仅是老师指派给我们的实验，我还学到了更多的知识，这次实验给我最大的心得就是，接触新知识，了解新知识，学习新知识，运用新知识。实验三系统的状态建模实验名称：系统的状态建模实验类型 :设计性实
12、验一、实验目的1熟悉状态图的基本功能和使用方法。2掌握如何使用建模工具绘制状态图方法。二、实验器材1计算机一台。2软件 Rational Rose 或 ArgoUML 、UMLet 、 StarUML 等三、实验内容完成实验一后， 对给定题目的系统的需求的初步分析，得出系统的用例图，通过对用例的业务流程的分析，我们可以初步了解系统的业务处理流程，但对业务处理过程的处理状态间转换了解仍不够，这不利于设计人员对系统业务的进一步理解，而状态图能从对象的动态行为的角度去描述系统的业务活动。因此，在本实验主要完成用例的状态图。四、实验步骤1业务分析：由前面实验对用例的描述和分析得到业务动态行为的状态分析
13、。以用例“还书”为例，还书业务的动态行为是由： 空闲（ idle ）、图书查找（ finding ）、还书（reversion）、失败（ Failure）、归还成功（ Success）5 种状态及激活相互转换的事件。2绘制状态图。还书的状态图， 还书的主要业务都是由管理员来完成， 首先管理员必须先登录系统， 并通过验证后，便可以进行下一步的操作，查找该书的相关信息，如存在，则进行还书操作，如不存在该信息，则给出提示信息；绘图步骤：（ 1）在用例图中的还书（ revesion）用例，单击右键， 新建一个状态图，命名为 revesion状态图，图3.1 所示。3.2 所示。图 3.1（ 2）双击“
14、 reversion”状态图，展开后，在左边的工具栏上选取一个实心圆点，此结点为开始结点；当还书的时候，操作者先要询问系统的状态，如果系统忙，操作者则必需等待，因此，得到系统的两种状态，如图图3.2（ 3）操作者在询问系统和状态后，得到的图3.3 所示两种状态，如果系统忙，操作者必需要等待、结束，如图3.4 和图 3.5 所示，重返步骤（1）。图 3.3图 3.4图3.5（ 4）如系统空闲，则进行对还书的信息进行查询操作，图一是查询得到该书的相关信息，二查询不到该书的相关信息；两种状态，如图3.7 所示。3.6 所示；查询也有两种结果，则此时有两种状态， 需要建立图 3.6图 3.7（ 5）最
15、后，操作者进行了操作后，系统会给出操作的结果给操作者；操作成功或失败，都会有提示信息给出。整个的还书的过程便完成；图3.8 所示。图 3.8（ 6）根据分析设计情况，进一步添加或细化状态图。五、实验心得体会完成实验一后， 对给定题目的系统的需求的初步分析，得出系统的用例图，通过对用例的业务流程的分析，我们可以初步了解系统的业务处理流程，但对业务处理过程的处理状态间转换了解仍不够，这不利于设计人员对系统业务的进一步理解，而状态图能从对象的动态行为的角度去描述系统的业务活动。因此，在本实验主要完成了用例的状态图。据我的进一步了解，用例的状态图的构建有以下几个步骤：步骤一：列出被测系统的输入事件；步骤二：将空闲状态加入所有可能的输入；步骤三：将新状态加入所有可能的输入；步骤四：对步骤 3 产生的新状态加入所有可能的输入 ；步骤五：对步骤 4 产生的新状态加入所有可能的输入；步骤六：编写测试用例流程表；步骤七：设计测试用例。对象拥有行为和状态。 对象的状态是由对象当前的行动和条件决定的。 状态图显示出了对象可能的状态以及由状态改变而导致的转移。总的来说， 此次的实验虽然是没有遇到什么大的困难，但是它在我对于学过程中的态度的影响是相当大的， 还是那句话，此次实验使我感触颇深的就是： 去接触未知，从而了解未知，进一步学习未知，最终学而致用。