uml学习心得体会.docx
《uml学习心得体会.docx》由会员分享，可在线阅读，更多相关《uml学习心得体会.docx（30页珍藏版）》请在冰豆网上搜索。
uml学习心得体会
uml学习心得体会
篇一：
UML学习心得耿庆博 UML学习心得
（一）UML（UnifiedModelingLanguage，统一建模语言）是一组用于描述OOAD进程的图形化表达方式。
UML为交流面向对象的设计中的需求，行为、体系结构的实现提供了一套综合的表示法。
（二）UML由9个不同类型的图组成：
用例图：
显示了系统的外部可视行为。
用例图描述了系统外的人员和系统的交互动作，和系统的响应，该类型的图能够用于描述系统的功能需求。
活动图：
显示系统行为的峡谷纳西描述。
活动图描述了单个功能需求内部的细节行为，包括大体的场景和一些可选的场景。
组件图：
显示了系统的体系结构。
组件图描述了系统的可部署单元（可执行文件，组件，数据存储和其他一些内容）和一些借口，可部署单元通过这些接口进行交互，该图能够用于研究系统的体系结构。
顺序图：
显示了对象随着时刻的交互。
顺序图描述了某个功能需求的途径或场景内相对时刻的详细行为，该图可用于明白得系统元素之间的消息流程。
协作图：
显示了对象的交互，强调对象之间的关系。
（在里面找不到了） 类图：
显示了类的概念和关系。
类图描述了系统设计中的类和接口，和他们之间的关系。
该图可用于概念内部的，面向对象的代码结构。
状态图：
显示了响应时刻的状态改变。
状态图描述了系统如何改变状态以相应内部的和外部的事件，确保每一个事件都被适当的处置。
部署图：
显示了系统的物理体系结构。
部署图描述了系统的可部署单元（应用，组件，数据存储等）如何被给予不同的节点，这些节点如何交互通信，用于系统映射和负载的研究。
包图：
显示了设计的层次结构。
包图描述了设计的相关元素如何按组结合在一路，和他们之间的关系。
（三）各类图的作用 1.用例图（UseCaseDiagram） 它是UML中最简单也是最复杂的一种图。
说它简单是因为它采纳了面向对象的思想，又是基于用户视角的，绘制超级容易，简单的图形表示让人一看就懂。
说它复杂是因为用例图往往不容易操纵，要么过于复杂，要么过于简单。
用例图表示了角色和用例和它们之间的关系。
2.类图（ClassDiagram） UML面向对象中是最经常使用的一种图，类图能够帮忙咱们更直观的了解一个系统的体系结构。
通过关系和类表示的类图，能够图形化的方式描述一个系统的设计部份。
UML面向对象中对象图是类图的实例，几乎利用与类图完全相同的标识。
它们的不同点在于对象图显示类的多个对象实例，而不是实例的类。
一个对象图是类图的一个实例。
由于对象存在生命周期，因此对象图只能在系统某一时刻段存在。
描述一个实体基于事件反映的动态行为，显示了该实体如何依照当前所处的状态对不同的时刻做出反映的。
通常创建一个UML状态图是为了以下的研究目的：
研究类、角色、子系统、或组件的复杂行为。
又称顺序图，描述了对象之间动态的交互关系，着重表现对象间消息传递的时刻顺序。
顺序图由一组对象组成，每一个对象别离带有一条竖线，称作对象的生命线，它代表时刻轴，时刻沿竖线向下延伸。
UML面向对象中顺序图描述了这些对象随着时刻的推移彼此之间互换消息的进程。
消息用从一务垂直的对象生命线指向另一个对象的生命线的水平箭头表示。
图中还能够依照需要增加有关时刻的说明和其他注释。
UML面向对象中协作图用于显示组件及其交互关系的空间组织结构，它并非偏重于交互的顺序。
协作图显示了交互中各个对象之间的组织交互关系和对象彼此之间的链接。
与序列图不同，协作图显示的是对象之间的关系。
另一方面，协作图没有将时刻作为一个单独的维度，因此序列号就决定了消息及并发线程的顺序。
协作图是一个介于符号图和序列图之间的交叉产物，它用带有编号的箭头来描述特定的方案，以显示在整个方案进程中消息的移动情形。
协作图用途：
通过刻画对象之间消息的移动情形来反映具体的方案。
显示对象及其交互关系的空间组织结构，而非交互的顺序。
7.活动图（ActivityDiagram） UML面向对象中UML活动图记录了单个操作或方式的逻辑，单个用户案例，或单个业务流程的逻辑。
描述系统中各类活动的执行顺序，通经常使用于描述一个操作中所要进行的各项活动的执行流程。
同时，它也常被用来描述一个用例的处置流程，或某种交互流程。
活动图由一些活动组成，图中同时包括了对这些活动的说明。
当一个活动执行完毕以后，操纵将沿着操纵转移箭头转向下一个活动。
活动图中还能够方便地描述操纵转移的条件和并行执行等要求。
8.组件图（ComponentDiagram） 组件图是用来反映代码的物理结构。
从组件图中，能够了解各软件组件（如源代码文件或动态链接库）之间的编译器和运行时依托关系。
利用组件图能够将系统划分为内聚组件并显示代码自身的结构。
组件图的要紧目的是显示系统组件间的结构关系。
UML面向对象中配置图描述系统中硬件和软件的物理配置情形和系统体系结构。
在配置图中，用结点表示实际的物理设备，如运算机和各类外部设备等，并依照它们之间的连接关系，将相应的结点连接起来，并说明其连接方式。
在结点里面，说明分派给该结点上运行的可执行构件或对象，从而说明哪些软件单元被分派在哪些结点上运行。
UML是一种软件建模语言，能够对任何具有静态结构和动态行为的系统进行建模。
在关注它建模特性的同时更要关注它的进程特性--在什么时刻做什么工作，用什么模型，让哪些人来做。
对系统用户而言，软件的开发模型向他们描述了软件开发者对软件系统需求的 明白得。
让系统用户查看软件对象模型而且找到其中的问题，能够使开发者不至于从一开始就发生错误。
对软件开发而言，软件的对象模型有助于他们对软件的需求和系统的架构和功能进行沟通。
对软件的保护和技术支持者而言，在软件系统开始运行后的相当长的一段时刻内，软件的对象模型能够帮忙他们明白得程序的架构和功能，迅速地对软件所显现的问题进行修复。
建模并非是仅对大型的软件系统，乃至一个小型的留言本也能从建模的进程中受益。
利用UML能够有效地解决软件设计和分析进程中的沟通和交流问题，能够高效的了解整个系统结构，而且在设计之初就将软件的设计结构和思想固化在纸上有利于规避项目实施进程中程序员离开的风险。
UML能够贯穿软件开发周期中的没一个时期，在开发时期，他能够用于说明、可视化、构建和书写面向对象软件制品的设计语言。
UML能贯穿整个软件开发进程是因为在每一个时期都能够提供相应相应的图形来对应，使得改变需求，设计代码，测试分析能变得相对简单。
在需求分析进程中，应该分为两个进程：
1需求的获取二、需求的分析。
需求的获取，往往不受到重视，在上常常看到有人说，专门是国内目前的情形，项目工期紧，公司往往想方设法先把项目拿下来，然后就拿自己公司以往做过的项目做蓝本，然后再依照顾客的需求改动，再次开发，测试，交付就完工了。
但如果是需求的获取，做不行，往往对后面的步骤流程造成专门大的阻碍，造成太多的改动和损失。
因此为了取得更好的需求，利用UML建模能变得相对简单。
例如需求的用例图对系统的功能模型的搭建。
用例间的关系有包括、扩展、泛化三类。
用例图包括角色、用例和关系。
角色能够有角色的描述，用例能够有效例的描述，这些描述在交流或评审中会超级有效。
用例能够泛化，泛化用例具有大体用例的功能，还能够做得更多。
角色也能够泛化，泛化角色能执行原角色能执行的所有效例，还能够执行更多的用例。
除大体用例，角色不能与包括用例、扩展用例和泛化用例有联系。
一个用例能够对应一个类图。
增、删、改、查一样来讲关于大多数应用做为一个简单的操作即可，没必要要作为一个用例来分析。
篇二：
uml学习体会 ——uml学习体会 养成良好的绘制uml序列图的适应 在学习uml的进程中，你可能会碰到绘制uml序列图的问题，那个地址就讨论一下如何才能养成良好的绘制uml序列图的适应。
有一些方式能够帮忙您提高uml序列图的质量和效劳。
它们包括：
和主题问题专家一路验证决策；使解决方案尽可能简单；为绘制消息和返回值选择一种一 致且有效的风格；将序列图分层；遵循一致的逻辑风格；牢记序列图是动态的。
一：
验证决策 绘制UML序列图时，我做了一些对其它模型可能有潜在阻碍的决策。
例如，在对第10步建模时，假设（大致上是个设计决策）费用显示屏幕同时也处置学生对费用是不是可同意所进行的验证。
该决策应该由用户界面原型反映出来，并由主题问题专家（SME）进行验证。
您应该和SME（专门是那些关于如何开发类似模型有着深刻观点的富有体会的人）一路执行序列图的绘制工作。
二：
维持简单 在对第2和第3步建模时，我突然意识到学生可能应该利用口令进入系统。
在向SME提出了那个概念后觉察我错了：
姓名和学号组合关于咱们的目的来讲已经足够唯一，而且学校也不希望增加复杂的口令治理。
这是个很成心思的决策，因为这是学校的一个运作策略，因此能够作为一条商业规那么记载到增补标准中。
通过与SME一路查验那个方式，而不是假定我比他们明白得更多，我幸免了“镀金”的机遇，因此减少了咱们小组开发这一系统所需的工作。
三：
绘制消息和返回值 绘制UML序列图时我更喜爱从左至右地绘制消息，从右至左地绘制返回值，尽管如此关于复杂的对象／类来讲不老是超级适合。
我将消息上的标签和返回值对齐到离箭头最近的位置。
我不喜爱在序列图上标出返回值，为的是使图尽可能地简化。
只是，始终标出返回值也一样有效，专门是在序列图用于设计而不是分析目的时。
（我希望我的分析图尽可能简单，而设计图尽可能全面。
）在分析期间，我的目标是明白得逻辑和确保逻辑的正确性。
而在设计期间，那么要给予消息精准的细节。
四：
将序列图分层 绘制UML序列图时我喜爱将序列图从左至右地分层。
先标出参与者，然后是操纵器类，然后是用户界面类，最后是商业类。
在设计期间，可能需要添加系统类和持久类，我通常将它们放在序列图的最右边。
以这种方式将序列图分层往往使它们更易于阅读，而且更易找出分层逻辑问题，例如用户界面类直接访问持久类。
五：
遵循一致的逻辑风格 请注意，在图1序列图所示的进程中，逻辑风格做了部份更改。
一开始，专门是在登录时，用户界面处置一些大体逻辑--而在选择研习班，和稍后的验证时，那么是操纵器类进行处置。
这事实上是个设计问题。
我可不能在那个问题上纠缠太久，但和往常一样，我建议选择一种适合于您的建模风格，然后始终如一地贯彻在所有序列图中。
六：
牢记序列图是动态的 绘制UML序列图时您可能听说过诸如动态建模和静态建模如此的术语，其他一些熟悉面向对象建模技术的开发人员常常会提到它们。
您乃至可能听到过有关每种风格的优势的争辩。
动态建模技术要紧集中在标识系统中的行为，包括序列图的绘制和活动图的绘制（请参阅“如何绘制UML活动图”）和UML协作图的绘制。
而静态建模那么集中在系统的静态方面，包括类、它们的属性，和类之间的关联。
类模型和持久／数据模型一样，都是静态建模的要紧产物。
因此事实上没有什么好争辩的--要想恰如其分地说明面向对象系统，同时需要动态和静态建模技术。
篇三：
UML学习心得体会 养成良好的绘制uml序列图的适应在学习uml的进程中，你可能会碰到绘制uml序列图的问题，那个地址就讨论一下如何才能 养成良好的绘制uml序列图的适应。
有一些方式能够帮忙您提高uml序列图的质量和效劳。
它们包括：
和主题问题专家一路 验证决策；使解决方案尽可能简单；为绘制消息和返回值选择一种一致且有效的风格；将序列图分层；遵循一致的逻辑风格；牢记序列图是动态的。
一：
验证决策 绘制uml序列图时，我做了一些对其它模型可能有潜在阻碍的决策。
例如，在对第10 步建模时，假设（大致上是个设计决策）费用显示屏幕同时也处置学生对费用是不是可同意所 进行的验证。
该决策应该由用户界面原型反映出来，并由主题问题专家（sme）进行验证。
您应 该和sme（专门是那些关于如何开发类似模型有着深刻观点的富有体会的人）一路执行序列 图的绘制工作。
二：
维持简单 在对第2和第3步建模时，我突然意识到学生可能应该利用口令进入系统。
在向sme提 出了那个概念后觉察我错了：
姓名和学号组合关于咱们的目的来讲已经足够唯一，而且学校 也不希望增加复杂的口令治理。
这是个很成心思的决策，因为这是学校的一个运作策略，所 以能够作为一条商业规那么记载到增补标准中。
通过与sme一路查验那个方式，而不是假定我 比他们明白得更多，我幸免了“镀金”的机遇，因此减少了咱们小组开发这一系统所需的工 作。
三：
绘制消息和返回值绘制uml序列图时我更喜爱从左至右地绘制消息，从右至左地绘制返回值，尽管如此对 于复杂的对象／类来讲不老是超级适合。
我将消息上的标签和返回值对齐到离箭头最近的位 置。
我不喜爱在序列图上标出返回值，为的是使图尽可能地简化。
只是，始终标出返回值也 一样有效，专门是在序列图用于设计而不是分析目的时。
（我希望我的分析图尽可能简单，而设 计图尽可能全面。
）在分析期间，我的目标是明白得逻辑和确保逻辑的正确性。
而在设计期间，那么 要给予消息精准的细节。
四：
将序列图分层 绘制uml序列图时我喜爱将序列图从左至右地分层。
先标出参与者，然后是操纵器类， 然后是用户界面类，最后是商业类。
在设计期间，可能需要添加系统类和持久类，我通常将 它们放在序列图的最右边。
以这种方式将序列图分层往往使它们更易于阅读，而且更易找 出分层逻辑问题，例如用户界面类直接访问持久类。
五：
遵循一致的逻辑风格请注意，在图1序列图所示的进程中，逻辑风格做了部份更改。
一开始，专门是在登录 时，用户界面处置一些大体逻辑--而在选择研习班，和稍后的验证时，那么是操纵器类进行 处置。
这事实上是个设计问题。
我可不能在那个问题上纠缠太久，但和往常一样，我建议选择 一种适合于您的建模风格，然后始终如一地贯彻在所有序列图中。
六：
牢记序列图是动态的绘制uml序列图时您可能听说过诸如动态建模和静态建模如此的术语，其他一些熟悉面 向对象建模技术的开发人员常常会提到它们。
您乃至可能听到过有关每种风格的优势的争辩。
动态建模技术要紧集中在标识系统中的行为，包括序列图的绘制和活动图的绘制（请参 阅“如何绘制uml活动图”）和uml协作图的绘制。
而静态建模那么集中在系统的静态方面， 包括类、它们的属性，和类之间的关联。
类模型和持久／数据模型一样，都是静态建模的 要紧产物。
（一）uml（unifiedmodelinglanguage，统一建模语言）是一组用于描述ooad进程的 图形化表达方式。
uml为交流面向对象的设计中的需求，行为、体系结构的实现提供了一套综合的表示法。
（二）uml由9个不同类型的图组成：
用例图：
显示了系统的外部可视行为。
用例图描述了系统外的人员和系统的交互动作，和系统的响应，该类型的图能够用于 描述系统的功能需求。
活动图：
显示系统行为的峡谷纳西描述。
活动图描述了单个功能需求内部的细节行为，包括大体的场景和一些可选的场景。
组件图：
显示了系统的体系结构。
组件图描述了系统的可部署单元（可执行文件，组件，数据存储和其他一些内容）和 一些借口，可部署单元通过这些接口进行交互，该图能够用于研究系统的体系结构。
顺序图：
显示了对象随着时刻的交互。
顺序图描述了某个功能需求的途径或场景内相对时刻的详细行为，该图可用于明白得系统 元素之间的消息流程。
协作图：
显示了对象的交互，强调对象之间的关系。
（在里面找不到了）类图：
显示了类的概念和关系。
类图描述了系统设计中的类和接口，和他们之间的关系。
该图可用于概念内部的，面 向对象的代码结构。
状态图：
显示了响应时刻的状态改变。
状态图描述了系统如何改变状态以相应内部的和外部的事件，确保每一个事件都被适当的 处置。
部署图：
显示了系统的物理体系结构。
部署图描述了系统的可部署单元（应用，组件，数据存储等）如何被给予不同的节点， 这些节点如何交互通信，用于系统映射和负载的研究。
包图：
显示了设计的层次结构。
包图描述了设计的相关元素如何按组结合在一路，和他们之间的关系。
（三）各类图的作用 1.用例图（usecasediagram）它是uml中最简单也是最复杂的一种图。
说它简单是因为它采纳了面向对象的思想，又 是基于用户视角的，绘制超级容易，简单的图形表示让人一看就懂。
说它复杂是因为用例图 往往不容易操纵，要么过于复杂，要么过于简单。
用例图表示了角色和用例和它们之间的 关系。
2.类图（classdiagram）uml面向对象中是最经常使用的一种图，类图能够帮忙咱们更直观的了解一个系统的体系结 构。
通过关系和类表示的类图，能够图形化的方式描述一个系统的设计部份。
uml面向对象中对象图是类图的实例，几乎利用与类图完全相同的标识。
它们的不同点 在于对象图显示类的多个对象实例，而不是实例的类。
一个对象图是类图的一个实例。
由于 对象存在生命周期，因此对象图只能在系统某一时刻段存在。
描述一个实体基于事件反映的动态行为，显示了该实体如何依照当前所处的状态对不同 的时刻做出反映的。
通常创建一个uml状态图是为了以下的研究目的：
研究类、角色、子系 统、或组件的复杂行为。
又称顺序图，描述了对象之间动态的交互关系，着重表现对象间消息传递的时刻顺序。
顺 序图由一组对象组成，每一个对象别离带有一条竖线，称作对象的生命线，它代表时刻轴，时 间沿竖线向下延伸。
uml面向对象中顺序图描述了这些对象随着时刻的推移彼此之间互换消 息的进程。
消息用从一务垂直的对象生命线指向另一个对象的生命线的水平箭头表示。
图中 还能够依照需要增加有关时刻的说明和其他注释。
uml面向对象中协作图用于显示组件及其交互关系的空间组织结构，它并非偏重于交互 的顺序。
协作图显示了交互中各个对象之间的组织交互关系和对象彼此之间的链接。
与序 列图不同，协作图显示的是对象之间的关系。
另一方面，协作图没有将时刻作为一个单独的 维度，因此序列号就决定了消息及并发线程的顺序。
协作图是一个介于符号图和序列图之间 的交叉产物，它用带有编号的箭头来描述特定的方案，以显示在整个方案进程中消息的移动 情形。
协作图用途：
通过刻画对象之间消息的移动情形来反映具体的方案。
显示对象及其交互关系的空间组织结构，而非交互的顺序。
7.活动图（activitydiagram）uml面向对象中uml活动图记录了单个操作或方式的逻辑，单个用户案例，或单个业 务流程的逻辑。
描述系统中各类活动的执行顺序，通经常使用于描述一个操作中所要进行的各项 活动的执行流程。
同时，它也常被用来描述一个用例的处置流程，或某种交互流程。
活动图由一些活动组成，图中同时包括了对这些活动的说明。
当一个活动执行完毕以后， 操纵将沿着操纵转移箭头转向下一个活动。
活动图中还能够方便地描述操纵转移的条件和 并行执行等要求。
组件图是用来反映代码的物理结构。
从组件图中，能够了解各软件组件（如源代码文件 或动态链接库）之间的编译器和运行时依托关系。
利用组件图能够将系统划分为内聚组件并 显示代码自身的结构。
组件图的要紧目的是显示系统组件间的结构关系。
uml面向对象中配置图描述系统中硬件和软件的物理配置情形和系统体系结构。
在配置图中，用结点表示实际的物理设备，如运算机和各类外部设备等，并依照它们之 间的连接关系，将相应的结点连接起来，并说明其连接方式。
在结点里面，说明分派给该结 点上运行的可执行构件或对象，从而说明哪些软件单元被分派在哪些结点上运行。
uml是一种软件建模语言，能够对任何具有静态结构和动态行为的系统进行建模。
在关 注它建模特性的同时更要关注它的进程特性--在什么时刻做什么工作，用什么模型，让哪些 人来做。
对系统用户而言，软件的开发模型向他们描述了软件开发者对软件系统需求的明白得。
让系统用户查看软件对象模型而且找到其中的问题，能够使开发者不至于从一开 始就发生错误。
对软件开发而言，软件的对象模型有助于他们对软件的需求和系统的架构 和功能进行沟通。
对软件的保护和技术支持者而言，在软件系统开始运行后的相当长的一段 时刻内，软件的对象模型能够帮忙他们明白得程序的架构和功能，迅速地对软件所显现的问题 进行修复。
建模并非是仅对大型的软件系统，乃至一个小型的留言本也能从建模的进程中受 益。
利用uml能够有效地解决软件设计和分析进程中的沟通和交流问题，能够高效的了解整 个系统结构，而且在设计之初就将软件的设计结构和思想固化在纸上有利于规避项目实施过 程中程序员离开的风险。
uml能够贯穿软件开发周期中的没一个时期，在开发时期，他能够 用于说明、可视化、构建和书写面向对象软件制品的设计语言。
uml能贯穿整个软件开发进程是因为在每一个时期都能够提供相应相应的图形来对应，使 得改变需求，设计代码，测试分析能变得相对简单。
在需求分析进程中，应该分为两个进程：
1需求的获取二、需求的分析。
需求的获取，往往不受到重视，在上常常看到有人说，特 别是国内目前的情形，项目工期紧，公司往往想方设法先把项目拿下来，然后就拿自己公司以 往做过的项目做蓝本，然后再依照顾客的需求改动，再次开发，测试，交付就完工了。
但如 果需求的获取，做不行，往往对后面的步骤流程造成专门大的阻碍，造成太多的改动和损失。
因此为了取得更好的需求，利用uml建模能变得相对简单。
例如需求的用例图对系统的功能 模型的搭建。
用例间的关系有包括、扩展、泛化三类。
用例图包括角色、用例和关系。
角色 能够有角色的描述，用例能够有效例的描述，这些描述在交流或评审中会超级有效。
用例可 以泛化，泛化用例具有大体用例的功能，还能够做得更多。
角色也能够泛化，泛化角色能执 行原角色能执行的所有效例，还能够执行更多的用例。
除大体用例，角色不能与包括用例、 扩展用例和泛化用例有联系。
一个用例能够对应一个类图。
增、删、改、查一样来讲关于大 多数应用做为一个简单的操作即可，没必要要作为一个用例来分析。
篇三：
uml实训总结实训总结（收成与体会）通过一个学期的uml学习，我从书本上获取了大体的理论知识，而真正的学以致用，将 书本理论知识运用到实际的进程，是这次uml实训的表现。
三个周的uml实训，主若是围绕着一个实训题目“基于uml系统需求分析与设计--合倍 利业务流治理系统”进行的，以小组为单位进行文档的编写，其中还对各类流程图、类图、 用例图等的绘制，整个进程设计了知识的方方面面。
从中让我熟悉到uml的作用和运作模式 和方式，它是一种统一建模的标准语言，此刻关于大多数软件开发来讲，都利用uml作为 建模语言，形成了统一的标准。
它是图形化的的语言，能够很直观的描述一个事物的状态、 行为与特点，专门好的说明与表达了“合贝利任务治理”那个系统。
总之，在我眼里，uml是一种概念良好、易于表达、功能壮大且普遍适用建模语言。
融 入软件工程领域的心思想、新方式和新技术，作用域不限于支持面向对象的分析和设计，也 不单纯是一种方式，仅仅是一组符号罢了，它能够对任何具有静态机构和动态行为的系统进 行建模，因此我很喜爱适用uml，在尔后的学习中，我还会进一步对该模型的学习，因为它 方便、简练、干净、清爽，直观形象，把整个软件系统的开发流程都融入进去。
这次实训进程中，文档方面的编写，碰到了很多的问题，这些问题主若是对基础知识的 明白得和把握不够，不能融会贯通和学以致用，有时碰到困难的时候真的不知如何着手解决， 可是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路”。
因此，当 碰到自己模糊和自己难以解决的问题时，向指导教师和懂的同窗请教，帮忙解决我碰到的问 题，通过他们的讲解后，我下来自己在分析，在动手，从不睬解到明白得，从可不能到会，从懂 到懂，这是一个让我学习愉快的进程，在那个进程中，既能够丰硕了自己的知识，还能够和 教师和同窗进行
升级会员 