uml实验报告总结
uml实验心得体会_0
uml实验心得体会篇一：UmL实训总结实训总结（收获与体会）通过一个学期的Uml学习，我从书本上获取了基本的理论知识，而真正的学以致用，将书本理论知识运用到实际的过程，是这次UmL 实训的体现。
三个周的UmL实训，主要是围绕着一个实训题目“基于UmL系统需求分析与设计--合倍利业务流管理系统”进行的，以小组为单位进行文档的编写，其中还对各种流程图、类图、用例图等的绘制，整个过程设计了知识的方方面面。
从中让我认识到UmL的作用和运作模式以及方法，它是一种统一建模的标准语言，现在对于大多数软件开发来说，都使用Uml作为建模语言，形成了统一的标准。
它是图形化的的语言，可以很直观的描述一个事物的状态、行为与特征，很好的说明与表达了“合贝利任务管理”这个系统。
总之，在我看来，UmL是一种定义良好、易于表达、功能强大且普遍适用建模语言。
融入软件工程领域的心思想、新方法和新技术，作用域不限于支持面向对象的分析和设计，也不单纯是一种方法，仅仅是一组符号而已，它可以对任何具有静态机构和动态行为的系统进行建模，所以我很喜欢适用UmL，在今后的学习中，我还会进一步对该模型的学习，因为它方便、简洁、干净、清爽，直观形象，把整个软件系统的开发流程都融入进去。
这次实训过程中，文档方面的编写，遇到了很多的问题，这些问题主要是对基础知识的理解和把握不够，不能融会贯通和学以致用，有时遇到困难的时候真的不知如何着手解决，但是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路”。
所以，当遇到自己模糊和自己难以解决的问题时，向指导老师和懂的同学请教，帮助解决我遇到的问题，经过他们的讲解后，我下来自己在分析，在动手，从不理解到理解，从不会到会，从懂到懂，这是一个让我学习愉快的过程，在这个过程中，既可以丰富了自己的知识，还可以和老师和同学进行有效地方沟通。
在这次实训过程中，感触最深的也就是合作精神了。
独木难成林，单枪匹马，那是最错误的思想和做法。
UML实验报告全
UML实验报告全实验报告：UML建模实验一、实验目的本实验旨在帮助学生掌握UML（统一建模语言）的基本概念、用法和建模过程，提高学生的软件建模能力。
二、实验内容1.了解UML的基本概念和用法；2.学习UML的各种图表，包括用例图、类图、序列图等；3.理解UML的建模过程，并能够按照该过程进行软件建模。
三、实验步骤1.学习UML的基本概念和用法。
在实验前，学生需要预习UML的基本知识，包括UML的定义、分类、语法规则等。
2.学习UML的各种图表。
UML提供了多种图表用于软件建模，如用例图、类图、对象图、活动图、状态图等。
学生需要了解每种图表的用途、语法和示例。
3.理解UML的建模过程。
在实际项目中，使用UML进行软件建模有一定的步骤，包括需求分析、设计、实现等。
学生需要了解UML的建模过程，并能够按照该过程进行实际建模。
4.实际操作。
学生需要选择一个简单的软件项目进行建模实践，包括绘制用例图、类图、序列图等，并撰写相应的文档。
5.分析和总结。
学生需要对实际操作进行分析和总结，包括建模过程中的问题和解决方法等，以便提高建模能力。
四、实验结果在本次实验中，我选择了一个简单的图书管理系统作为建模实践对象。
首先，我绘制了该系统的用例图，用于描述系统的功能和用户角色。
然后，我绘制了该系统的类图，用于描述系统的数据结构和类之间的关系。
最后，我绘制了该系统的序列图，用于描述系统中对象之间的交互过程。
在实际操作中，我遇到了一些问题。
首先，我发现在绘制用例图时，有些用例的描述不够清晰，无法准确描述用户需求。
为了解决这个问题，我与用户进行了沟通，并修改了用例的描述，使其更加明确。
其次，在绘制类图时，我发现有些类的关系没有考虑到，导致系统的完整性受到了影响。
为了解决这个问题，我仔细分析了系统的数据结构，并修改了类的关系，使其更加准确。
通过本次实验，我学到了很多关于UML建模的知识和技巧。
我发现UML是一种非常强大和灵活的建模语言，可以帮助我们更好地理解和设计软件系统。
UML实训总结
一. 实训综述1.1 实训地点1.2 实训性质、目的及意义性质: 在学完课本知识之后, 进行上岗之前的专业技能的培训, 通过培训来运用所学的知识。
二．目的: 通过培训能够掌握以后工作中所要用的知识。
明确软件工程师的工作职责、内容。
熟练掌握该软件工程师岗位的工作内容。
把学校所学理论知识与实际更好地结合起来, 提高解决实际问题的能力, 为毕业后从事实际工作奠定良好基础。
三．意义：在平时的学习中, 我们学习的都是课本上的纯理论的知识, 不懂得它的真正用处, 培训能够让我们所学的知识得以应用, 还可以加深专业的知识, 也培训我们实际的操作能力, 为以后的找工作提供了强力的帮助。
四．实训内容1.UML基础建模在软件开发过程中, 特别是数据库软件工程通常需要一套标准来辅助软件开发工作。
UML就是其中的一种标准。
UML可以实现大型复杂的系统各种成分描述的可视化, 说明并构造系统模型, 以及建立各种所需的文档, 它是一种定义良好, 易于表达, 功能强大且普遍使用的建模语言。
UML作为一种模型语言, 它使开发人员专注于建立产品的模型和结构, 而不是选用什么程序语言和算法实现。
当模型建立之后, 模型可以被UML工具转化成指定的程序语言代码。
UML是一种标准的软件建模语言, 是一种用于对软件系统的模型绘制可视化的标准蓝图或者以图表的方式对所研究的系统进行可视化描述的工具。
它的核心是一系列的图, 这些图从不同角度描述了整个系统。
UML中定义了九种图, 即：用例图、类图、对象图、状态图、顺序图、协作图、活动图、组件图和部署图。
从应用的角度看, 当采用面向对象技术设计系统时, 首先是描述需求, 其次根据需求建立系统的静态模型, 以构造系统的结构, 第三步是描述系统的行为。
UML可以归纳为需求模型、静态模型和动态模型三大类。
以下是按照一系列图的形式来分别介绍UML中图的元素。
用例图:用例图是显示一组用例、参与者以及它们之间关系的图, 主要用于对系统、子系统或类的行为进行建模, 包括：参与者、用例等元素。
uml实训总结（范本）
uml实训总结uml实训总结篇一：UML实训总结实训总结（收获与体会）通过一个学期的Uml学习，我从书本上获取了基本的理论知识，而真正的学以致用，将书本理论知识运用到实际的过程，是这次UML实训的体现。
三个周的UML 实训，主要是围绕着一个实训题目“基于UML系统需求分析与设计--合倍利业务流管理系统”进行的，以小组为单位进行文档的编写，其中还对各种流程图、类图、用例图等的绘制，整个过程设计了知识的方方面面。
从中让我认识到UML的作用和运作模式以及方法，它是一种统一建模的标准语言，现在对于大多数软件开发来说，都使用U ml作为建模语言，形成了统一的标准。
它是图形化的的语言，可以很直观的描述一个事物的状态、行为与特征，很好的说明与表达了“合贝利任务管理”这个系统。
总之，在我看来，UML是一种定义良好、易于表达、功能强大且普遍适用建模语言。
融入软件工程领域的心思想、新方法和新技术，作用域不限于支持面向对象的分析和设计，也不单纯是一种方法，仅仅是一组符号而已，它可以对任何具有静态机构和动态行为的系统进行建模，所以我很喜欢适用UML，在今后的学习中，我还会进一步对该模型的学习，因为它方便、简洁、干净、清爽，直观形象，把整个软件系统的开发流程都融入进去。
这次实训过程中，文档方面的编写，遇到了很多的问题，这些问题主要是对基础知识的理解和把握不够，不能融会贯通和学以致用，有时遇到困难的时候真的不知如何着手解决，但是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路”。
所以，当遇到自己模糊和自己难以解决的问题时，向指导老师和懂的同学请教，帮助解决我遇到的问题，经过他们的讲解后，我下来自己在分析，在动手，从不理解到理解，从不会到会，从懂到懂，这是一个让我学习愉快的过程，在这个过程中，既可以丰富了自己的知识，还可以和老师和同学进行有效地方沟通。
uml实验心得体会（范本）
uml实验心得体会u ml实验心得体会篇一：UM L实验报告 UML实验报告学院班级学号姓名 UML实验报告实验一：用例图实验结果：小结实验心得体会：用例模型用于需求分析阶段，它描述了待开发系统的功能需求，并驱动了需求分析之后各阶段的开发工作。
用例图是UML中用来对系统的动态方面进行建模的7种图之一。
用例图描述了用例、参与者以及它们之间的关系。
用例图从用户角度描述系统功能，并指出各功能的操作者。
通过本次实验，我熟悉Ratina l Rse建模环境，更加清楚的了解了用例图的语义和功能，如何清晰明了的识别参与者、用例，学会了如何使用事件流描述用例。
同时掌握了用例间的类属关系、Include关系和Extend关系的语义、功能和应用。
最后通过本次实验学习了如何使用用例图为系统的上下文以及系统的需求建模。
思考题：1. 如果要删除参与者、用例，请问是在导航窗口删除，还是在绘图窗口删除？答：都可以删除，但在绘图窗口中有两种删除方式：一种是只删除参与者、用例，而不改变其在导航窗口中的存在，另一种是从建模中完全删除。
2. 如果要删除参与者和用例的联系，用例和用例的联系，请问是在绘图中删除，还是在参与者或用例的设置对话框中删除？答：都可以删除。
实验二：类对象模型的建立实验结果：小结实验心得体会：类图是面向对象系统建模最常用的图，描述了类图、接口集、协作以及它们之间的关系。
类图描述了系统的静态设计视，该视主要体现系统的功能需求，即系统应该提供给用户的服务。
通过本次实验，加深了我对类图语义的理解和功能的应用，掌握了类之间的联系，关联、依赖、聚合等，同时基本掌握了在Ra tinal Rse中绘制类的关联、依赖、泛化关系。
思考题：选中一个模型对象，点击鼠标右键，比较快捷菜单项“Ed it——Delete”与“Edit——D elete frmMdel”，它们二者之间区别在哪里？答：“Edit——Delete”只是在绘图窗口中删除了模型对象，而“Edi t ——Deletefrm Mdel”则是彻底的删除了模型对象。
uml实验报告
uml实验报告UML实验报告。
一、实验目的。
本实验旨在通过对UML（Unified Modeling Language，统一建模语言）的学习和实践，掌握UML的基本概念、语法和建模方法，能够运用UML对系统进行分析、设计和建模。
二、实验内容。
1. 了解UML的基本概念和发展历程；2. 掌握UML的基本语法和建模元素；3. 学习使用UML对系统进行需求分析、概念建模、系统设计和详细设计。
三、实验过程。
1. UML基本概念和发展历程。
UML是一种用于软件开发的建模语言，它提供了一种统一的、标准的建模方法，可以帮助软件开发人员进行系统分析和设计。
UML的发展经历了多个版本的更新和完善，目前最新的版本是UML 2.x。
通过学习UML的基本概念和发展历程，我们对UML有了更深入的了解，为后续的学习和实践打下了基础。
2. UML的基本语法和建模元素。
UML包括了多种建模元素，如用例图、类图、时序图、活动图等。
每种建模元素都有其特定的语法和符号表示方法，通过学习这些基本语法和建模元素，我们能够准确地使用UML对系统进行建模和描述。
3. 使用UML进行系统分析、设计和建模。
在掌握了UML的基本语法和建模元素后，我们开始了对系统的分析、设计和建模工作。
首先，我们对系统进行了需求分析，明确了系统的功能和性能需求；然后，我们进行了概念建模，绘制了用例图和类图；接着，我们进行了系统设计，绘制了时序图和活动图；最后，我们进行了详细设计，完善了系统的各项细节。
四、实验总结。
通过本次实验，我们深入学习了UML的基本概念、语法和建模方法，掌握了使用UML进行系统分析、设计和建模的技能。
在实践中，我们对UML的各种建模元素有了更深入的理解，能够准确地运用UML对系统进行描述和设计。
同时，我们也意识到UML是一个非常强大和实用的工具，能够帮助我们更好地进行软件开发和项目管理。
综上所述，本次实验对我们的学习和成长都具有重要意义，我们将继续深入学习和实践UML，不断提升自己的建模能力和软件开发水平。
uml 实验报告
uml 实验报告UML 实验报告导言：UML（Unified Modeling Language）是一种用于软件工程的建模语言，它提供了一种统一的标准，用于描述、构建和可视化软件系统的结构和行为。
在本次实验中，我们将探索 UML 的使用，并通过实际案例来展示其在软件开发中的重要性和应用价值。
一、UML 的基本概念和原则UML 是一种图形化的建模语言，它由一系列的图表和符号组成，用于描述软件系统的不同方面。
在 UML 中，最常用的图表包括用例图、类图、时序图和活动图等。
每种图表都有其特定的应用场景和表示方式，通过这些图表的组合使用，我们可以更清晰地理解和表达软件系统的结构和行为。
二、用例图的应用用例图是 UML 中最常用的图表之一，它主要用于描述系统的功能需求和用户与系统之间的交互。
通过用例图，我们可以清楚地了解系统的各个角色和功能，并可以更好地定义系统的边界和范围。
在实际开发中，用例图常被用于需求分析和系统设计的初期阶段，它可以帮助团队成员更好地理解和沟通系统的需求和功能。
三、类图的建模类图是 UML 中用于描述系统的静态结构的图表，它主要用于表示系统中的类、接口、关系和属性等。
通过类图，我们可以清楚地了解系统中各个类之间的关系和依赖，从而更好地进行系统设计和代码编写。
类图不仅可以帮助我们理清系统的结构，还可以提供给开发者一个清晰的指导，使他们能够更高效地编写代码和进行系统维护。
四、时序图的分析时序图是 UML 中用于描述系统的动态行为的图表，它主要用于表示系统中对象之间的交互和消息传递。
通过时序图，我们可以清晰地了解系统中不同对象之间的时序关系和消息传递过程，从而更好地理解系统的行为和流程。
时序图常被用于系统设计和代码调试的过程中，它可以帮助开发者更好地理解和排查系统中的问题。
五、活动图的应用活动图是 UML 中用于描述系统的业务流程和控制流程的图表，它主要用于表示系统中活动和行为的顺序和条件。
UML实验报告范文
UML实验报告范文实验报告：UML图的设计与应用一、实验目的1. 学习掌握UML（Unified Modeling Language）的基本语法、概念和使用方法；2.了解UML各种图的作用和应用场景；3.进行实际案例的UML建模。
二、实验内容与原理1.UML概述UML是一种面向对象软件开发的标准建模语言，它可以帮助设计师、开发者和用户理解问题领域、设计解决方案并进行沟通。
UML建模图主要有用例图、类图、时序图、活动图、状态图和部署图等，用于描述系统的不同层面。
2.用例图用例图是描述系统功能和参与者之间交互的一种图。
参与者表示与系统交互的角色，用例表示系统的功能需求。
用例图是进行需求分析与系统设计的重要工具之一3.类图类图是描述系统中类以及它们之间关系的一种图。
类图由类、关联、聚合、组合、泛化、实现等元素组成，用于描述系统的静态结构。
4.时序图时序图是描述对象之间消息传递的一种图。
时序图主要用于描述系统中其中一特定操作的交互过程，时序图中的对象称为参与者，他们通过消息进行交互。
5.活动图活动图是描述系统中流程和操作的一种图，用于描述系统中活动的业务流程。
活动图可以展示控制流、对象流和数据流，用于描述系统的动态行为。
6.状态图状态图是描述系统中对象状态变化及其转换的一种图。
状态图展示了对象在不同状态之间的转换过程，用于描述系统的状态机。
7.部署图部署图是描述系统中物理部署和组件之间关系的一种图。
部署图主要用于展示系统的物理结构和系统组件之间的关联情况。
三、实验过程1.确定需求分析并编写用例图根据题目要求和系统需求，确定需求分析，绘制用例图。
用例图主要包括参与者和用例，参与者与用例之间通过关系进行关联。
2.分析系统结构并编写类图根据用例图和系统需求，分析系统结构，识别出系统中的类、接口和关系，绘制类图。
类图包括类、接口、关联、聚合、组合、泛化和实现等元素。
3.分析用户操作流程并绘制时序图根据用例图和系统需求，分析用户操作流程，确定对象的活动顺序，绘制时序图。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
本科实验报告课程名称：计算机网络实验项目：计算机网络实验地点：逸夫楼404专业班级：软件1319班学号：********** 学生姓名：***指导教师：**目录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顺序图的建模及其思想。