UML学习心得体会

第一篇：UML学习心得体会

——uml学习体会

养成良好的绘制uml序列图的习惯 在学习uml的过程中，你可能会遇到绘制uml序列图的问题，这里就讨论一下怎样才能养成良好的绘制uml序列图的习惯。

有一些方法可以帮助您提高uml序列图的质量和效力。它们包括：和主题问题专家一起验证决策；使解决方案尽量简单；为绘制消息和返回值选择一种一

致且有效的风格；将序列图分层；遵循一致的逻辑风格；牢记序列图是动态的。一：验证决策

绘制uml序列图时，我做了一些对其它模型可能有潜在影响的决策。例如，在对第10步建模时，假设（大致上是个设计决策）费用显示屏幕同时也处理学生对费用是否可接受所进行的验证。该决策应该由用户界面原型反映出来，并由主题问题专家(sme)进行验证。您应该和sme（特别是那些对于如何开发类似模型有着深刻见解的富有经验的人）一起执行序列图的绘制工作。

二：保持简单

在对第2和第3步建模时，我忽然意识到学生可能应该使用口令进入系统。在向sme提出了这个概念后发觉我错了：姓名和学号组合对于我们的目的来说已经足够唯一，并且学校也不希望增加复杂的口令管理。这是个很有意思的决策，因为这是学校的一个运作策略，所以可以作为一条商业规则记载到增补规范中。通过与sme一起检验这个想法，而不是假定我比他们知道得更多，我避免了“镀金”的机会，因而减少了我们小组开发这一系统所需的工作。

三：绘制消息和返回值

绘制uml序列图时我更喜欢从左至右地绘制消息，从右至左地绘制返回值，尽管这样对于复杂的对象／类来说不总是非常合适。我将消息上的标签和返回值对齐到离箭头最近的位置。我不喜欢在序列图上标出返回值，为的是使图尽可能地简化。不过，始终标出返回值也同样有效，特别是在序列图用于设计而不是分析目的时。（我希望我的分析图尽量简单，而设计图尽量全面。）在分析期间，我的目标是理解逻辑和确保逻辑的正确性。而在设计期间，则要赋予消息精确的细节。

四：将序列图分层 绘制uml序列图时我喜欢将序列图从左至右地分层。先标出参与者，然后是控制器类，然后是用户界面类，最后是商业类。在设计期间，可能需要添加系统类和持久类，我通常将它们放在序列图的最右侧。以这种方式将序列图分层往往使它们更易于阅读，并且更容易找出分层逻辑问题，例如用户界面类直接访问持久类。

五：遵循一致的逻辑风格

请注意，在图1序列图所示的过程中，逻辑风格做了部分更改。一开始，特别是在登录时，用户界面处理一些基本逻辑--而在选择研习班，以及稍后的验证时，则是控制器类进行处理。这实际上是个设计问题。我不会在这个问题上纠缠太久，但和往常一样，我建议选择一种适合于您的建模风格，然后始终如一地贯彻在所有序列图中。

六：牢记序列图是动态的绘制uml序列图时您可能听说过诸如动态建模和静态建模这样的术语，其他一些熟悉面向对象建模技术的开发人员常常会提到它们。您甚至可能听到过有关每种风格的优点的争论。动态建模技术主要集中在标识系统中的行为，包括序列图的绘制和活动图的绘制（请参阅“如何绘制uml活动图”）以及uml协作图的绘制。而静态建模则集中在系统的静态方面，包括类、它们的属性，以及类之间的关联。类模型和持久／数据模型一样，都是静态建模的主要产物。uml学习心得(一)uml（unified modeling language，统一建模语言）是一组用于描述ooad过程的图形化表达方式。uml为交流面向对象的设计中的需求，行为、体系结构的实现提供了一套综合的表示法。(二)uml由9个不同类型的图组成：

用例图：显示了系统的外部可视行为。

用例图描述了系统外的人员和系统的交互动作，以及系统的响应，该类型的图可以用于描述系统的功能需求。

活动图：显示系统行为的峡谷纳西描述。

活动图描述了单个功能需求内部的细节行为，包括基本的场景和一些可选的场景。

组件图：显示了系统的体系结构。

组件图描述了系统的可部署单元（可执行文件，组件，数据存储和其他一些内容）以及一些借口，可部署单元通过这些接口进行交互，该图可以用于研究系统的体系结构。

顺序图：显示了对象随着时间的交互。

顺序图描述了某个功能需求的路径或场景内相对时间的详细行为，该图可用于理解系统元素之间的消息流程。

协作图：显示了对象的交互，强调对象之间的关系。（在uml2.0里面找不到了）

类图：显示了类的定义和关系。

类图描述了系统设计中的类和接口，以及他们之间的关系。该图可用于定义内部的，面向对象的代码结构。

状态图：显示了响应时间的状态改变。

状态图描述了系统如何改变状态以相应内部的和外部的事件，确保每个事件都被适当的处理。

部署图：显示了系统的物理体系结构。

部署图描述了系统的可部署单元（应用，组件，数据存储等）如何被赋予不同的节点，这些节点如何交互通信，用于系统映射和负载的研究。

包图：显示了设计的层次结构。

包图描述了设计的相关元素如何按组结合在一起，以及他们之间的关系。(三)各种图的作用

1.用例图（usecasediagram）

它是uml中最简单也是最复杂的一种图。说它简单是因为它采用了面向对象的思想，又是基于用户视角的，绘制非常容易，简单的图形表示让人一看就懂。说它复杂是因为用例图往往不容易控制，要么过于复杂，要么过于简单。用例图表示了角色和用例以及它们之间的关系。

2.类图（classdiagram）uml面向对象中是最常用的一种图，类图可以帮助我们更直观的了解一个系统的体系结构。通过关系和类表示的类图，可以图形化的方式描述一个系统的设计部分。3.对象图 uml面向对象中对象图是类图的实例，几乎使用与类图完全相同的标识。它们的不同点在于对象图显示类的多个对象实例，而不是实例的类。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。4.状态图

描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常创建一个uml状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。5.时序图

又称顺序图，描述了对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。顺序图由一组对象构成，每个对象分别带有一条竖线，称作对象的生命线，它代表时间轴，时间沿竖线向下延伸。uml面向对象中顺序图描述了这些对象随着时间 的推移相互之间交换消息的过程。消息用从一务垂直的对象生命线指向另一个对象的生命线的水平箭头表示。图中还可以根据需要增加有关时间的说明和其他注释。6.协作图 uml面向对象中协作图用于显示组件及其交互关系的空间组织结构，它并不侧重于交互的顺序。协作图显示了交互中各个对象之间的组织交互关系以及对象 彼此之间的链接。与序列图不同，协作图显示的是对象之间的关系。另一方面，协作图没有将时间作为一个单独的维度，因此序列号就决定了消息及并发线程的顺 序。协作图是一个介于符号图和序列图之间的交叉产物，它用带有编号的箭头来描述特定的方案，以显示在整个方案过程中消息的移动情况。

协作图用途：

通过描绘对象之间消息的移动情况来反映具体的方案。

显示对象及其交互关系的空间组织结构，而非交互的顺序。7.活动图（activitydiagram）uml面向对象中uml活动图记录了单个操作或方法的逻辑，单个用户案例，或者单个业务流程的逻辑。描述系统中各种活动的执行顺序，通常用于描述一个操作中所要进行的各项活动的执行流程。同时，它也常被用来描述一个用例的处理流程，或者某种交互流程。

活动图由一些活动组成，图中同时包括了对这些活动的说明。当一个活动执行完毕之后，控制将沿着控制转移箭头转向下一个活动。活动图中还可以方便地描述控制转移的条件以及并行执行等要求。

组件图是用来反映代码的物理结构。从组件图中，可以了解各软件组件（如源代码文件或动态链接库）之间的编译器和运行时依赖关系。使用组件图可以将系统划分为内聚组件并显示代码自身的结构。

组件图的主要目的是显示系统组件间的结构关系。9.配置图

uml面向对象中配置图描述系统中硬件和软件的物理配置情况和系统体系结构。

在配置图中，用结点表示实际的物理设备，如计算机和各种外部设备等，并根据它们之间的连接关系，将相应的结点连接起来，并说明其连接方式。在结点里面，说明分配给该结点上运行的可执行构件或对象，从而说明哪些软件单元被分配在哪些结点上运行。uml是一种软件建模语言，可以对任何具有静态结构和动态行为的系统进行建模。在关注它建模特性的同时更要关注它的过程特性--在什么时间做什么工作，用什么模型，让哪些人来做。对系统用户而言，软件的开发模型向他们描述了软件开发者对软件系统需求的理解。让系统用户查看软件对象模型并且找到其中的问题，可以使开发者不至于从一开始就发生错误。对软件开发而言，软件的对象模型有助于他们对软件的需求以及系统的架构和功能进行沟通。对软件的维护和技术支持者而言，在软件系统开始运行后的相当长的一段时间内，软件的对象模型能够帮助他们理解程序的架构和功能，迅速地对软件所出现的问题进行修复。建模并不是仅对大型的软件系统，甚至一个小型的留言本也能从建模的过程中受益。利用uml可以有效地解决软件设计和分析过程中的沟通和交流问题，可以高效的了解整个系统结构，并且在设计之初就将软件的设计结构和思想固化在纸上有利于规避项目实施 过程中程序员离开的风险。uml可以贯穿软件开发周期中的没一个阶段，在开发阶段，他可以用于说明、可视化、构建和书写面向对象软件制品的设计语言。uml能贯穿整个软件开发过程是因为在每个阶段都能够提供相应相应的图形来对应，使得改变需求，设计代码，测试分析能变得相对简单。在需求分析过程中，应该分为两个过程：1 需求的获取

2、需求的分析。需求的获取，往往不受到重视，在网上经常看到有人说，特别是国内目前的情况，项目工期紧，公司往往想方设法先把项目拿下来，然后就拿自己公司 以往做过的项目做蓝本，然后再根据顾客的需求改动，再次开发，测试，交付就完工了。但如果需求的获取，做不好，往往对后面的步骤流程造成很大的影响，造成 太多的改动和损失。所以为了得到更好的需求，使用uml建模能变得相对简单。例如需求的用例图对系统的功能模型的搭建。用例间的关系有包含、扩展、泛化三类。用例图包括角色、用例和关 系。角色可以有角色的描述，用例可以有用例的描述，这些描述在交流或评审中会非常有用。用例可以泛化，泛化用例具有基本用例的功能，还可以做得更多。角色 也可以泛化，泛化角色能执行原角色能执行的所有用例，还可以执行更多的用例。除了基本用例，角色不能与包含用例、扩展用例和泛化用例有联系。一个用例可以 对应一个类图。增、删、改、查一般来说对于大多数应用做为一个简单的操作即可，不必要作为一个用例来分析。篇三：uml实训总结 实训总结（收获与体会）

通过一个学期的uml学习，我从书本上获取了基本的理论知识，而真正的学以致用，将书本理论知识运用到实际的过程，是这次uml实训的体现。

三个周的uml实训，主要是围绕着一个实训题目“基于uml系统需求分析与设计--合倍利业务流管理系统”进行的，以小组为单位进行文档的编写，其中还对各种流程图、类图、用例图等的绘制，整个过程设计了知识的方方面面。从中让我认识到uml的作用和运作模式以及方法，它是一种统一建模的标准语言，现在对于大多数软件开发来说，都使用uml作为建模语言，形成了统一的标准。它是图形化的的语言，可以很直观的描述一个事物的状态、行为与特征，很好的说明与表达了“合贝利任务管理”这个系统。总之，在我看来，uml是一种定义良好、易于表达、功能强大且普遍适用建模语言。融入软件工程领域的心思想、新方法和新技术，作用域不限于支持面向对象的分析和设计，也不单纯是一种方法，仅仅是一组符号而已，它可以对任何具有静态机构和动态行为的系统进行建模，所以我很喜欢适用uml，在今后的学习中，我还会进一步对该模型的学习，因为它方便、简洁、干净、清爽，直观形象，把整个软件系统的开发流程都融入进去。

这次实训过程中，文档方面的编写，遇到了很多的问题，这些问题主要是对基础知识的理解和把握不够，不能融会贯通和学以致用，有时遇到困难的时候真的不知如何着手解决，但是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路”。所以，当遇到自己模糊和自己难以解决的问题时，向指导老师和懂的同学请教，帮助解决我遇到的问题，经过他们的讲解后，我下来自己在分析，在动手，从不理解到理解，从不会到会，从懂到懂，这是一个让我学习愉快的过程，在这个过程中，既可以丰富了自己的知识，还可以和老师和同学进行有效地方沟通。

在这次实训过程中，感触最深的也就是合作精神了。独木难成林，单枪匹马，那是最错误的思想和做法。这次我是深有感触了。对于一个系统的分析，到最终项目的完成，需要分析每个文档，然后在写出纸质的文档，而在每个文档中，内容比较多，分析也要求比较到位，所以单独凭借一个人去完成，似乎有点困难，于是我们小组，将每个文档进行分析，能独立成块就分配给每一个人，这样，每个人都有自己的任务，谁也不会闲着，既学到了知识，也充实了自己。另外一点，就是我深深体会到了积累知识的重要性。在实训当中我们遇到了不少难题，但是经过我们大家的讨论和老师细心的一一指导，问题得到了解决。两个月的实训结束了，收获颇丰，同时也更深刻的认识到要做一个合格的程序员并非我以前想像的那么容易，最重要的还是细致严谨。社会是不会要一个一无是处的人的，所以我们要更多更快地从一个学生向工作者转变，总的来说我对这次实习还是比较满意的，它使我学到了很多东西，为我以后的学习做了引导，点明了方向。实训的日子即将结束，回想这一个过程，有过痛苦，有过烦恼，有过喜悦和有过成功。痛苦烦恼的是自己对所学书本知识掌握得不是很扎实，面对着从书本上学到的知识与实际联系不起来，总结起来就是自己的动手练习的时间太少。而喜悦的是，在做的过程中遇到了困难和问题，主动向老师和会的同学请教，然后再做，直至做正确做成功后的那种喜悦。

团队的力量是无穷的，通过组员的共同努力，完成了实训项目。虽然，我们这组的项目存在着诸多的不足和缺点，但这正是以后学习和工作需要弥补的。这次实训将为我以后进入社会提过了一笔宝贵的财富，是对我能力的一个见证。最后，不得不感谢指导教师熊飞老师的辛勤指导，和小组成员的共同努力！篇四：uml课设心得

六月23号至六月27号，是我们班进行uml专用周课程设计的时间，虽然时间并不是很长，只有短短的一个星期而已，但是让我受益匪浅，通过这次的uml课程设计，使我所学的书本知识得到了全面的检验，也让我对这门课程有了更加深厚的体会。

这次课程设计我们没有另外选题，而是在我们之前做过的系统之上加以完善和改进。现在看看之前提交的作品，确实不近人意；但经过在网上的不断查找资料，终于还是将它完成。之前我做的系统状态图和活动图，为了锻炼自己这次选择了交互图（也就是时序图和协作图）。虽然说自己没有这方面的经验，也不是特别熟悉其工作流程，但是有了在网上 查找资料得来的一些基础和课本里的讲解，自己对它也有了一定初步的认识，虽然不是很全面，但还是跌跌撞撞的完成。其中还因为和组员没有沟通好导致用的类不同，费了好大劲才改回来。

最后，这次课设使我们发现考试真的并不是最重要，最重要的是能运用所学的知识。在整个uml课程的学习过程中，我们突破了传统学习模式，把被动接受转变为主动学习。不再是用学到的知识解题，而是在实际运用时遇到什么学什么，重在把知识应用于实际。立体的运用比死板的模仿更有效也更容易接受。下学期就大四了，也就是大学校园里的最后一年，而课设里学到的动手能力和分析问题解决问题的能力也将是我们毕业找工作的一大筹码。篇五：uml学习重点汇总

第一章 oom&软件建模概述 uml（unified modeling language）

通用的标准建模语言,可以对任何具有静态结构和动态行为的系统进行建模。标准建模语言uml适用于以面向对象技术来描述任何类型的系统,而且适用于系统开发的不同阶段,从需求规格描述直至系统完成后的测试和维护。

特点：统一标准，面向对象，可视化、表达能力强，独立于过程，uml很适合于以体系结构中心的、用例驱动的、迭代式和渐增式的软件开发过程 第二章 uml构成 1.uml的“4+1视图”

从某个角度观察系统构成系统的一个视图，每个

数据库

5活动图——泳道图

泳道将活动图中的活动化分为若干组，并把每一视图都是系统描述的一个投影，说明了系统某个侧面的特征。（1）用例视图（2）逻辑视图（3）组件视图（4）进程视图（并发视图）（5）配置视图（部署视图）2.uml的模型图：

模型图是一组uml模型元素构成的有向图表示，它通常由一组节点（uml基本模型元素）, 及节点之间的连线（关系）组成。(1)用例视图：用例图(2)静态模型：类图、对象图、包图、构件图和配置图(3)动态模型：活动图、顺序图、状态图和协作图 3.用例图.用例图是表达用例和参与者及其关系的载体。关系包括：关联关系，依赖关系 实现关系： 3.用例图(续)——用例之间关系1（包含与扩展）.3.用例图(续)——用例之间关系2（泛化）.3.用例图(续)——用例与参与者

用例use case：一组用例的实例（场景），其中每个实例都是系统执行的一系列活动，这些活动产生了对每个参与者而言可观察的返回值。描述了从参与者角度看系统做了什么

用例模型本身不是面向对象建模技术。

参与者actor: 是指在系统外部与系统交互的人或其他系统，以某种方式参与了系统内用例的执行。4.交互式视图图(顺序图、协作图)1）协作图：采用图的形式展示对象间的交互 2）顺序图：采用栅栏格式展示对象间的交互

顺序图与协作图的优缺点： 顺序图

（优点）强调消息的时间顺序及对象生命线（优点）大量详细表示法选项

（缺点）强制在右侧增加新对象，消耗空间大 协作图（优点）强调结构组织，复杂交互表达更容易（优点）空间利用率高，和方便添加新对象（缺点）不宜查询消息的顺序，表示法选项少 5 活动图

活动图用于表示完成一个操作所需要的活动，或者是一个用例实例（场景）的活动。活动图适合描述动作流和并发处理行为。5活动图——实例

组指定给负责这组活动的业务组织即对象。泳道区分了负责活动的对象，明确地表示了哪些活动是由哪些对象进行的。

每个活动只能明确地属于一个泳道。6 状态图（状态机）

状态图(state diagram)一个对象在其生存期间的动态行为，表现对象响应事件所经历的状态序列以及伴随的动作。并不是所有类都有相应的状态图。状态图只适用于：具有若干个确定状态，类的行为在这些状态下 会受到影响且被不同的状态改变。

状态图与活动图的区别与联系（1）相同的图形符号。

（2）描述一个系统或对象在生存周期的状态或行为。（3）描述系统或对象在多进程中同步或异步操作并发行为。

（4）用条件分支来描述系统或对象的行为控制流。联系：

（2）描述多个对象共同完成一个操作的机制不同。活动图置于责任区（泳道）中，责任区将活动按责任目标和组织归属的原则分类。状态图采用状态嵌套方式描述多

对象协作。

7、类图

类图表示系统中类及类和类之间的关系，用于对系统的静态结构进行描述。类用来表示系统中需要处理的事物.类的关系：

（1）关联：关联表示两个类的对象之间存在某种语义上的联系。

（2）聚集：聚集也称为聚合，关联的特例 聚集表示类与类之间的关系是整体与部分的关系。

（3）泛化：uml中的泛化关系就是通常所说的继承关系，它是通用元素和具体元素之间的一种分类关系。（4）依赖和细化。2)类的关系——关联

间具有细化关系。细化用来协调不同阶段模型之间的关系。

构件图由构件、接口及构件之间的关系组成。构件图主要用于系统的静态实现视图模型，通过构件的依赖关系描述系统软件的组织结构，展示系统不同物理构件及其关系。

系统业务模型：业务过程和文档。系统开发管理模型：开发期间产物及关系 系统实现模型：系统实现的构件建模

第六章 从需求到设计 包图（package diagram）概念性的模型管理工具，用于将大型的软件系统中大量的建模元素有序的组织起来。

运用包可以把语义上相近的可能一起变更的模型元素组织在同一个包中，对包中的元素作为一个整体对待，并 2)类的关系——聚集

聚集也称为聚合，是关联的特例。聚集表示类与类之间的关系是整体与部分的关系。

（1.共享聚集 聚合：聚集关系中处于部分方的对象可同时参与多个处于整体方对象的构成.（2.组合聚集.组合：部分类完全隶属于整体类.部分与整体共存.整体不存在部分也随之消失。2)类的关系——泛化 uml中的泛化关系就是通常所说的继承关系（或一般与特殊关系）。2)类的关系——依赖

两个类之间有依赖，表明其中一个类.客户类.依赖于另一个类（供应类）所提供的某些服务。2)类的关系——细化

当对同一个事物在不同抽象层次上描述时，这些描述之

系统物理配置模型：数据文件、日志、安装/卸载等文件且控制它们的可视性和存取。包拥有内容，包括类、接构件建模 口、组件、节点、协同。use case、图，甚至其它包。集成系统模型：对api建模，帮助利用已有组件。第三章 unified process(1)构件: 系统中遵从并实现一组接口的物理的、可替换up的构成：二维的面向对象开发模型，兼顾技术和管理。的软件模块。构件是软件复用的基本物理实现单元，是工作流:过程工作流(业务建模+需求+分析与设计+实施+逻辑元素模型（类、接口、协同等）的物理包

测试+部署)和3个支持工作流（配置和变更管理+项目管理+环境）4个阶段：初始＋细化＋构造＋交付 up的迭代策略。

up的迭代开发策略:以体系结构为中心，以质量管理和

风险控制为目标，以用例为驱动，采用迭代式以螺旋上

升的模式进行软件开发。(2)构件的接口:一个构件可以定义对其他构件可见的接第四章 初始阶段(inception)口。构件间依赖通过指向所使用的构件接口来表示。接1.初始阶段的目标和任务：

口描述一个构件能提供服务的操作，是一个有操作而无做适当的调研，以形成对新系统的整体目的和可实现的类。包括输入和输出接口。

行性形成一个合理的意见。

建立项目的软件范围和边界条件，包括一个操作“前景”，“接受准则”和产品中包含什么，不包含什么„ 确定核心的用例，这是系统运行的主要场景，它将决定系统设计的方案

针对主要的场景，确定或者演示至少一个备选的系统结9 部署图（deployment diagram）

构

由节点和节点之间的联系组成，描述了处理器、设备和对整个项目估计总成本和计划(更详细的估计将安排在软件构件运行时的体系结构。

细化阶段中)估计可能的风险(不可预计性的来源）为项目准备支持环境 2.初始阶段的制品： 用例模型＋用例描述，词汇表，补充性规格说明，前景，业务规则 9 部署图——结点 3.用例描述

节点是存在于运行时的代表计算资源的物理元素，可摘要：简介描述用例，通常只给出主成功场景。以代表一种物理硬件设备或软件元素。非正式：用若干非正式段落来描述用例，通常给出多个包含：处理器和设备两种类型 不同场景。

详述：详细描述用例，通常给出所有的步骤及场景，并10 部署图——结点间联系

给出前置和后置条件等细节 节点间通过物理连接发生联系，以从硬件方面保证注意：用例描述的方法 系统各节点之间的协同运行。包括通讯关联、依赖联系4.用例的获取过程

等。(1)选择系统边界(2)寻找参与者(3)确定每个参与者的目标(4)定义用例 5.用例的定义:一般为每一个用户目标定义用例

确定用例的经验方法：

(1)老板测试：必须看到可量化的价值(2)ebp：能够增加可量化的业务价值，并且以持久状态留下数据(3)规模测试： 6.rup与用例

(1)意义：记录功能需求；迭代计划的重要部分，预算的关键输入；实现驱动设计；影响用户手册和测试(2)初始阶段：确定系统目标、范围、涉众；绝大部分摘要描述、10～20％详述；确定是否继续开发(3)细化阶段：80～90％被细化描述；分多次迭代(4)构造阶段：多次时间定量迭代；补充次要用例 第五章 细化阶段(elaboration)1.细化阶段的目标和任务: 8.系统顺序图

表述系统是什么，而不解释它是如何做的，将系统作为黑盒子 系统顺序图

它展示了对一个特定的用例，外部的参与者产生的事件，它们的顺序以及系统内的事件

协作与耦合从较高层到较低层进行，避免从较低层到较高层的耦合第七章 模式与对象设计 1 职责和职责驱动设计 类的契约和责任，分为：行为职责和认知职责。在对象设计中，职责被分配给对象，称为rdd。2 设计模式

设计模式：对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。即，对特定问题的描述或解决方案。

目的: 易于理解，维护，扩展和重用 3 grasp模式 控制器（controller），创建者（creator），信息专家 构建核心体系架构，解决高风险问题，完成绝大部分需求的定义，并估计并估计总体计划和资源，保证架构，需求和计划足够稳定，风险被充分规避，确定和解决项目中所有与架构密切相关的风险，从与架构密切相关的场景中确定一个基准体系架构，产生一个达到产品级质量水准的演化性原型，也可以是一个或更多个探索型抛弃型原型，能够展示基准的体系架构以合理的价格和合适的时间支持系统需求，建立一个支持环境 2.核心活动: 尽快定义和验证体系架构，并确定体系架构基线 细化设想（vision）为构造阶段建立详细的迭代计划并建立基线 细化开发用例并将其部署到开发环境中 细化体系架构并选择组件 3.关键思想和实践

实行短时间定量、风险驱动的迭代，及早开始编程，对架构核心和风险部分进行适应性设计，实现和测试，尽早，频繁，实际的测试，基于来自测试，用户，开发者的反馈进行调整，通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次 4.制定迭代计划: 通过风险、覆盖范围和关键程度组织需求和迭代。

风险：技术复杂性；其他因素

覆盖性：在早期迭代中，系统中主要的部分都有所涉及 关键性：具有高业务价值的功能

在每个迭代前将用例和特征进行排序 迭代单位：(1)用例；(2)场景 5.细化阶段的制品: 领域模型，设计模型，软件架构文档，数据模型，用例示意板，用户界面模型 6.领域模型(domain model)领域模型是对真实世界中概念类的表示，而不是软件对象的表示。它不是用来描述软件类、软件架构领域层或有职责软件对象的一组图。

领域模型用一套类图表示，但类没有操作。领域模型可以显示：领域对象或者概念类；概念类之间的关联；概念类的属性

概念类来源：现实（组织、地点、设备等）对象；业务（业务实体和概念）对象；过程（需要记录的时间）对象。9.操作契约

通过领域模型中的对象的状态变换(实例创建或删除;属性修改;关联形成或者打破)，定义了系统操作执行后的详细的系统行为.契约co2: enteritem 操作 : enteritem(itemid: itemid, quantity: integer)前提（preconditions）: there is a sale underway 后置条件（postconditions）: 一个saleslineitem的实例sli被创建；sli与当前的 sale 对象相关联；sli.quantity的数值被赋值，依据itemid的匹配，sli 与productspecification相关联 第六章 从需求到设计 1.软件的逻辑体系结构

逻辑架构（logical architecture）是软件类的宏观组织结构，它将软件类组织成包（命名空间），子系统和层等。

层（layer）：对类、包或子系统的粗粒度的分组，具有对系统主要方面加以内聚的职责。较高的层可以调用较低的层。常见的层：

用户界，应用逻辑和领域对象，技术服务 典型的分层模式 2.软件架构

架构是一组重要决策，其中涉及软件系统的组织，对结构元素及其组成系统的接口的选择，这些元素特定于其相互协作的行为，这些结构和行为元素到规模更大的子系统的组成，以及指导该组织结构的架构风格。3.分层设计模式（模型-视图分离, 如mvc架构）系统的大型逻辑结构组织为独立的，职责相关的离散层，具有清晰内聚的关注分离。较低的层是低级别和一般性服务，较高的层则是与应用相关。（information expert），高度内聚（high cohesion），低耦合（low coupling）4 命令——查询分类原则

执行动作（更新、调整）的命令方法，这种方法通常具有改变对象状态等副作用，并且是 void 的（没有返回值）。向调用者返回数据的查询，这种方法没有副作用，不会永久性的改变任何对象的状态。一个方法不应该同时属于以上两种类型。

第二篇：UML实验心得体会

uml实验报告

学院

班级 学号 姓名

uml实验报告

实验一：用例图

实验结果：

小结实验心得体会：

用例模型用于需求分析阶段，它描述了待开发系统的功能需求，并驱动了需求分析之后各阶段的开发工作。用例图是uml中用来对系统的动态方面进行建模的7种图之一。用例图描述了用例、参与者以及它们之间的关系。用例图从用户角度描述系统功能，并指出各功能的操作者。通过本次实验，我熟悉rational rose建模环境，更加清楚的了解了用例图的语义和功能，如何清晰明了的识别参与者、用例，学会了如何使用事件流描述用例。同时掌握了用例间的类属关系、include关系和extend关系的语义、功能和应用。最后通过本次实验学习了如何使用用例图为系统的上下文以及系统的需求建模。

思考题：

1.如果要删除参与者、用例，请问是在导航窗口删除，还是在绘图窗口删除？

答：都可以删除，但在绘图窗口中有两种删除方式：一种是只删除参与者、用例，而不改变 其在导航窗口中的存在，另一种是从建模中完全删除。

2.如果要删除参与者和用例的联系，用例和用例的联系，请问是在绘图中删除，还是 在参与者或用例的设置对话框中删除？

答：都可以删除。

实验二：类对象模型的建立

实验结果：

小结实验心得体会：

类图是面向对象系统建模最常用的图，描述了类图、接口集、协作以及它们之间的关系。类图描述了系统的静态设计视，该视主要体现系统的功能需求，即系统应该提供给用户的服

务。通过本次实验，加深了我对类图语义的理解和功能的应用，掌握了类之间的联系，关联、依赖、聚合等，同时基本掌握了在rational rose中绘制类的关联、依赖、泛化关系。

思考题：选中一个模型对象，点击鼠标右键，比较快捷菜单项“edit——delete”与“edit——delete from model”，它们二者之间区别在哪里？

答：“edit——delete”只是在绘图窗口中删除了模型对象，而“edit——delete from model”则是彻底的删除了模型对象。

实验三：顺序图、协作图

实验结果：

顺序图：

1.归还图书

2.借出图书

协作图：

1.归还图书

2.借出图书

小结实验心得体会：

顺序图描述了对象之间的动态合作关系，它强调对象之间消息发送的时间顺序，同时显示对象之间的交互。协作图与顺序图是同构的，rose可自动转换。顺序图是强调消息的交互作用图，协作图描述了对象间的关系，是强调发送和接收消息的对象的组织结构的交互作用图。通过本次实验，掌握了对图书管理功能中的借书用例、还书用例进行动态建模。实验过程中由于对rational rose工具软件的不熟识，导致出现了不该出现的错误。在设计阶段，顺序图中需要引入边界类和控制类，在识别对象职责的基础上，需要将消息转换为类的方法，为方法定义参数、返回值类型，便于计算机的实现。其中，为方法定义参数、返回值类型的时候，还是不能够快速准确的作出判断。

实验四：活动图

实验结果：

篇二：uml实验总结

实验一

1．源代码生成，在逻辑视图中绘制下图，生成java源文件 生成代码步骤：

“tools”-〉“java”-〉“genenate codes”。

public class meeting { private string username;private string scheduled_user;private date start_time;private date end_time;private string label;public string getuser(){ return null;} public string getother(){ return null;} public date getstart(){ return null;} public date getend(){ return null;} public string getlabel(){ return null;} public string tostring(){ return null;} public void main(string args){ return null;} } 2．进行逆向工程，自行找到一个项目软件源代码，进行逆向工程。（ftp上有一个小源程序文件）

逆向工程的实现

“tools”->“java”-〉“reverse engineer java„”。public class student { private string name;public student(){ } public void test(){ } } 实验二

根据下属需求，分析参与者和用例，并建立网络教学系统的用例图。网络教学系统的功能需求主要包括以下几个方面： ① 学生可以登录网站浏览信息、查找信息和下载文件。②

教师可以登录网站输入课程简介、上传课件文件、发布消息、修改和更新消息。③ 系统管理员可以对页面维护以及批准用户的注册申请。

录入课程简介

下载文件 查找信息

修改消息

注册信息处理

实验三

1、已知借书的活动图如图3所示，若要求欠费的读者需结清欠款才能借书，请完善该活动图，并在rose内绘制出来。

图3 借书处理活动图

2、图4为图书“借书”活动图，文字描述此活动图包括哪些活动，活动按照怎样的顺序发生？

图4 “借书处理”活动图

（1）读者查找所需的图书，若找到图书，将所需的图书带到借阅台；（2）工作人员输入读者信息，检查读者身份是否合法，如果读者身份合法，进入（3）；

（3）录入图书信息，并检查图书是否允许借阅，如果允许，则记录借阅信

息，否则直接进入（4）；

（4）检查是否还有图书需要录入，如果还需录入，进入（3），否则提借阅信息。

3、绘制“删除读者信息”用例的活动图。删除读者信息一般按照以下步骤进行：

（1）管理员在录入界面，输入待删除的读者名；

（2）“业务逻辑”组件在数据库中，查找待删除的读者名；

（3）如果不存在，则显示出错信息，返回步骤（1），如果存在则继续；（4）“业务逻辑”组件判断“待删除的读者”是否可以删除；

（5）如果不可以，则显示出错信息，返回步骤（8），如果可以则继续；（6）在数据库中，删除相关信息；（7）显示删除成功信息；（8）结束。

篇三：uml实训总结

实训总结（收获与体会）

通过一个学期的uml学习，我从书本上获取了基本的理论知识，而真正的学以致用，将书本理论知识运用到实际的过程，是这次uml实训的体现。

三个周的uml实训，主要是围绕着一个实训题目“基于uml系统需求分析与设计--合倍利业务流管理系统”进行的，以小组为单位进行文档的编写，其中还对各种流程图、类图、用例图等的绘制，整个过程设计了知识的方方面面。从中让我认识到uml的作用和运作模式以及方法，它是一种统一建模的标准语言，现在对于大多数软件开发来说，都使用uml作为建模语言，形成了统一的标准。它是图形化的的语言，可以很直观的描述一个事物的状态、行为与特征，很好的说明与表达了“合贝利任务管理”这个系统。

总之，在我看来，uml是一种定义良好、易于表达、功能强大且普遍适用建模语言。融入软件工程领域的心思想、新方法和新技术，作用域不限于支持面向对象的分析和设计，也不单纯是一种方法，仅仅是一组符号而已，它可以对任何具有静态机构和动态行为的系统进行建模，所以我很喜欢适用uml，在今后的学习中，我还会进一步对该模型的学习，因为它方便、简洁、干净、清爽，直观形象，把整个软件系统的开发流程都融入进去。

这次实训过程中，文档方面的编写，遇到了很多的问题，这些问题主要是对基础知识的理解和把握不够，不能融会贯通和学以致用，有时遇到困难的时候真的不知如何着手解决，但是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路”。所以，当遇到自己模糊和自己难以解决的问题时，向指导老师和懂的同学请教，帮助解决我遇到的问题，经过他们的讲解后，我下来自己在分析，在动手，从不理解到理解，从不会到会，从懂到懂，这是一个让我学习愉快的过程，在这个过程中，既可以丰富了自己的知识，还可以和老师和同学进行有效地方沟通。

在这次实训过程中，感触最深的也就是合作精神了。独木难成林，单枪匹马，那是最错误的思想和做法。这次我是深有感触了。对于一个系统的分析，到最终项目的完成，需要分析每个文档，然后在写出纸质的文档，而在每个文档中，内容比较多，分析也要求比较到位，所以单独凭借一个人去完成，似乎有点困难，于是我们小组，将每个文档进行分析，能独立成块就分配给每一个人，这样，每个人都有自己的任务，谁也不会闲着，既学到了知识，也充实了自己。另外一点，就是我深深体会到了积累知识的重要性。在实训当中我们遇到了不少难题，但是经过我们大家的讨论和老师细心的一一指导，问题得到了解决。两个月的实训结束了，收获颇丰，同时也更深刻的认识到要做一个合格的程序员并非我以前想像的那么容易，最重要的还是细致严谨。社会是不会要一个一无是处的人的，所以我们要更多更快地从一个学生向工作者转变，总的来说我对这次实习还是比较满意的，它使我学到了很多东西，为我以后的学习做了引导，点明了方向。

实训的日子即将结束，回想这一个过程，有过痛苦，有过烦恼，有过喜悦和有过成功。痛苦烦恼的是自己对所学书本知识掌握得不是很扎实，面对着从书本上学到的知识与实际联系不起来，总结起来就是自己的动手练习的时间太少。而喜悦的是，在做的过程中遇到了困难和问题，主动向老师和会的同学请教，然后再做，直至做正确做成功后的那种喜悦。

团队的力量是无穷的，通过组员的共同努力，完成了实训项目。虽然，我们这组的项目存在着诸多的不足和缺点，但这正是以后学习和工作需要弥补的。这次实训将为我以后进入社会提过了一笔宝贵的财富，是对我能力的一个见证。最后，不得不感谢指导教师熊飞老师的辛勤指导，和小组成员的共同努力！篇四：uml实验报告

学 生 实 验 报 告 书

实验课程名称

uml建模技术

开 课 学 院

指导老师姓名

学 生 姓 名

学生专业班级

2009 — 2010学年 第 一 学期

实验课程名称： uml建模技术

实验课程名称：

uml建模技术

篇五：uml实验——状态图 实验报告

南京信息工程大学实验(实习)报告

实验名称 状态图 实验(实习)日期 2014.04.26 得分 指导老师

系专业 班级

一、实验目的

1．熟悉活动图的基本功能和使用方法。

2．掌握如何使用建模工具绘制活动图方法。

二、实验器材

1．计算机一台。

2．rational rose 工具软件。

三、实验内容

通过前面内容的学习，完成了对图书馆的图书馆管理系统的需求的初步分析，得出系统的用例图和相应的活动态。通过这两类图我们可以初步了解系统的业务处理过程，但对业务处理过程的处理状态间转换了解仍不够，这不利于设计人员对系统业务的进一步理解，而状态图能从对象的动态行为的角度去描述系统的业务活动。因此，指派你运用本节所学的状态图，完成如下任务：

1.完成图书业务模块中还书用例的状态图。

四、实验步骤 1．业务分析：由前面章节对图书馆管理系统中的还书主要业务的描述和分析可知，还书业务的动态行为是由：空闲（idle）、图书查找（finding）、还书（reversion）、失败（failure）、归还成功（success）5种状态及激活相互转换的事件。

2．绘制状态图：请您根据分析运用uml绘制还书用例的状态图。

分析：

还书的状态图，还书的主要业务都是由管理员来完成，首先管理员必须先登录系统，并通过验证后，便可以进行下一步的操作，查找该书的相关信息，如存在，则进行还书操作，如不存在该信息，则给出提示信息；

绘图步骤：

（1）在用例图中的还书（revesion）用例，单击右键，如图3.1所示，新建一个状态图，命名为revesion状态图。

（2）双击“receivesion”状态图，展开后，在左边的工具栏上选取一个实心圆点，此结点为开始结点；当还书的时候，操作者先要询问系统的状态，如果系统忙，操作者则必需等待，因此，得到系统的两种状态。

（3）操作者在询问系统和状态后，得到两种状态，如果系统忙，操作者必需要等待、结束，重返步骤（1）。

（4）如系统空闲，则进行对还书的信息进行查询操作；查询也有两种结果，一是查询得到该书的相关信息，二查询不到该书的相关信息；则此时有两种状态，需要建立两种状态。

（5）最后，操作者进行了操作后，系统会给出操作的结果给操作者；操作成功或失败，都会有提示信息给出。整个的还书的过程便完成。

（7）根据分析设计情况，进一步添加或细化状态图。

五、实验报告要求

1．整理实验结果。

2．小结实验心得体会。

通过本次试验学习到了项目中状态图的绘制，了解了他们之间的关系以及关系处理的方法，熟悉了对rational rose 工具软件的使用，在以后做软件项目设计有很大的帮助。

第三篇：UML JSP课程设计心得体会

在这次课程设计过程中，在这与代码为伴的一个月里，我真的收获了很多。这次软件工程大型课程设计，既巩固了这学期学的UML知识，又复习了关于数据库和java的知识，更是学会了如何将所学知识运用到实际，真正的应用到软件开发、网站开发中来。

这次课程设计还有一个额外收获，就是初步学会了用JSP开发网页。虽然做出来的网页不是特别美观，有些地方还存在一些瑕疵，但是从对网页编程一窍不通到能做出一个功能基本完善的简单的毕业设计选题系统，一步步走来，其中收获的不仅仅是全新的知识，对于自学能力、动手能力、合作能力甚至接受挑战的勇气方面的影响，也都是巨大的。对于我来说，以前只接触过用C语言在DOS界面下编程，用java编写简单的桌面应用程序，最多只是简单的连接数据库，所以一开始听说要编网页的时候，实在是缺乏信心，在编程过程中遇到一些棘手的问题的时候，甚至一度想要逃避，可最终还是坚持下来了。虽然这点小程序对于熟练掌握网页编程语言的人来说不算什么，但对于我来说，没有接触过的东西，就是一个新挑战，任何语言的学习，在入门的时候都是最困难的。现在对于网页编程已经有了一个初步的了解，对于有些概念的理解还不是很准确，不过会努力在以后的学习过程中慢慢理解，在以后的编程过程中慢慢熟悉这些概念。

除了学习新语言的收获外，在编程过程中对于功能的实现、一些异常的处理还有界面的设计，也有着很深的感触。既然要做毕业设计选题系统，那么就要先考虑到用户的功能需求，分析不同的用户都是要通过网站做什么，每个用户都有哪些权限；对于数据库的操作来说，是要向数据库中插入数据，还是更新还是删除。而且要考虑到各个方面异常的处理，比如用户名、密码错误怎么办，输入的信息错误怎么处理，成功更新数据库信息后要弹出什么提示框，要转入那个页面等等。对于异常处理，我做的还不够好，由于时间精力有限，有一些异常情况没有考虑到，功能实现的还不够完美，在以后的编程过程中我会在力所能及的范围内尽量考虑周全，既然要做程序，那就要尽量做的完善。对于界面的设计，由于时间关系，没有采用流行的Dreamweaver，感觉有点遗憾，网页的背景图片都是自己手工合成的，略显简陋了些，唯一值得欣慰的就是实现了我一直想要的布局效果，以后在美工方面也会努力的提高自己的能力。

另外对于实际应用中课程之间的融合也是有了一个初步的概念。一开始总觉得UML没有什么实际的用处，但通过这次课程设计我发现，每门课程都是有它独特的意义的，UML中画出的类图、顺序图、活动图等等都对自己编程过程有着极佳的指导意义，这些图能使编程思路变得更加清晰。

总而言之，这一个月的感受可谓五味杂陈，是三言两语难以说清的，最明显的还是感觉到自己知识的不足，对于一些东西还是缺乏一个系统的准确的理解。java是门很有用的语言，考试范围之外的东西还有很多很多；JSP让我接触到了全新的网页编程，也让我知道，学无止境，想要全面深入的掌握一门语言，还是要付出很大的努力的。

第四篇：UML实验报告

一：需求分析

在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。我们在日常生活中也经常和ATM打交道。本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。二：银行ATM机系统UML建模设计 1.用例图

参与者“银行储户”和ATM机。简化后的ATM机仅有取款、存款及其余功能。其余功能不做详细说明。

银行储户在ATM机上完成取款、存款及其他业务。2.类图

整个银行系统包括了帐户库、银行储户库及ATM系统。

许多单个的帐户组成了帐户库。帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。

setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。getType获取帐户类型，返回类型为char，无参数。

setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。getAccountNumbe获取帐户号，返回类型为int，无参数。

caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。getBalance获取帐户余额，返回类型为double，无参数。

许多银行储户组成了储户库。ATM系统包含了许多ATM机。银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。同样对于一个真正的银行系统，这个类图过于简单。比如帐户类型我们可以先定义一个abstract class，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract class，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。

3.顺序图

描述顾客在ATM机上取款时信息的流动情况。以时间为顺序。因为是示例图，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。

通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个“X”，这是因为这个流程中还未遇到有对象生命结束。当有对象生命结束时需在对应的生命线终端画“X”，表明这个对象在这时被销毁。

首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来….银行储户读卡机显示输入设备客户管理点钞机事务管理1: 插入ATM卡2: 接受ATM卡3: 查询密码4: 显示输入密码请求5: 输入密码6: 密码传递7: 请求确认密码的合法性8: 确认密码的合法性9: 询问服务类别10: 显示输入服务类别请求11: 输入取款请求12: 取消请求13: 询问取款数额14: 显示输入数额请求15: 输入取款数额16: 传递取款数额17: 询问取款数额确认18: 显示确认数额请求19: 输入确认20: 传递确认信息21: 数额合法性确认请求22: 确认数额的合法性23: 计算储户余额24: 出钞请求25: 出钞26: 取钞27: 传递余额并询问是否需要其它服务28: 显示储户余额并显示其它服务

第五篇：UML实验报告[推荐]

UML实验报告

班 级：软件0841

姓 名：张文成 学 号：081842173

实验内容：

用例建模、分析建模、设计建模（1）、设计建模（2）

实验一：用例建模

[实验目的] 〃掌握客户需求分析的方法和步骤

〃了解以用例驱动的软件开发方法 〃识别并编写用例

〃掌握用Rose 进行用例建模的具体方法和步骤

[实验内容] 要求学生根据周围的实际情况，自选一个小型应用项目，分析业务需求，识别并编写用例、绘制用例图以理解系统需求。亦可采用教师指定的“企业综合信息管理系统”中的“进销存管理子系统”

[实验原理和步骤] 建模原理：

(1)需求获取。以任务和客户为中心，通过会议、面谈等手段对客户需求进行调研，获得系统目标、范围和功能要求的初步说明。(2)用例分析。确定用例，同时采用分层思想，对用例的层次级别进行划分（高层用例、子系统级、用户目标级）

（3）用例描述。分层绘制用例图，撰写用例的文字描述（采用单栏格式）。

步骤：

（1）需求获取。自选题目，与相关客户、领域专家等反复商讨，获得系统目标、范围和功能要求的初步说明。（也可采用教师指定的题目：“企业综合信息管理系统”中的“进销存管理子系统”，但要仔细研读“企业现状”、“系统目标、范围和功能要求”等文字说明）。（2）用例分析。确定系统范围和边界、确定参与者、确定用例。（3）用例描述。分层绘制用例图、描述用例。

画图原理：

采用Rose 软件进行用例建模必须建立在完好的系统用例分析基础之上．只有做好系统用例分析，系统用例建模才能这到预期的效果。步骤：

（1）分层绘制用例图，每层采用“包”进行管理。

（2）以“企业综合信息管理系统”-> “进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”为主线，完成附录2 中的操作过程（亦可选择“企业综合信息管理系统”-> “进销存管理”子系统-> “库存管理”-> “原材料出库”->“领料单处理”主线）

[ 实验结果]

实验2 分析建模

[ 实验目的](1)理解面向对象系统分析和对象类建模(概念建模)的概念(2)了解和掌握面向对象系统分析的方法和步骤(3)了解和掌握寻找待开发系统中类(概念)的方法和技巧(4)掌握使用ROSE 绘制概念模型的方法

[ 实验内容] 在用例分析的基础上，选择第一个迭代周期打算开发的用例，建立相关的概念模型。

[ 实验原理和步骤] 建模原理：

(1)使用概念目录列表（见下图）和非正式分析法（识别出问题域的文本描述中的名词短语，然后将其作为概念或属性的候选对象。）相结合的方法识别概念。因此，待开发用例的文字描述中，名词可能成为概念或属性的候选对象；表示行为的动词词组有可能成为事务型或过程型对象；形容词词组有可能对应抽象的名词型概念。

采用的技术基本上就是：ER 图+纯行为+OO 的聚合、泛化。（2）最终关联的数量介于“需要知道”型关联与【“需要知道”型关联+“需要理解”型（从通用关联列表中派生出 的，见下图）】之间。

步骤：

（1）识别关键用例作为第一个迭代周期的开发目标（一般是在用例图中被依赖得比较多的用例）。可以选“企业综合信息管理系统”-> “进销存管理”子系统-> “库存管理”-> “原材料出库”->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统”-> “进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。（其实，选“库存管理”主线更合适；当然，如果要实现产销一体化，以销售订单指导生产和采购，并实现零库存目标，那么一切工作就以销售管理为中心。即便如此，首选“增加合同”用例也更为合适。）

（2）识别概念和重要属性。

（3）建立概念间的关联。

画图原理：

（1）可以采用“逻辑视图”下的类图描述概念模型，只不过每个类中只有类名和属性，没有方法。在概念建模 阶段也没有必要确定属性的类型和访问属性。

（2）概念间的关联可以采用一般关联（无方向实线），当然，对于聚合和泛化，应采用相应的连线（组合：实心菱形+实线；聚合：空心菱形+实线；泛化：空三角形+实线）

步骤：

（0）前提条件：第一个迭代周期可以选“企业综合信息管理系统”

-> “进销存管理”子系统-> “库存管理”->“原材料出库”->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统”->“进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。做好与此用例相关的概念模型

（1）建立相关的概念模型的基础上，在“逻辑视图”下的类图中描述概念模型，可以直接在类图main 中绘制，也可采用类似用例图中用过的分包机制

(2）绘制概念和重要属性。（3）绘制概念间的关联。

[ 实验结果]

[ 实验总结] ① 对重点实验结果进行分析；

② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。

③ 收获与体会：筛选概念的要点；区分概念与属性的要点；关联取舍的要点；画图时如何防止关联重名。

实验3 设计建模（1）

[ 实验日期]2011年5月20日 [ 实验目的](1)理解顺序图的基本概念

（2）了解和掌握软件工程中用例逻辑时序的分析方法（3）掌握使用ROSE 创建顺序图的方法

[ 实验内容] 在用例模型和概念模型的基础上，对首选的用例进行事件分解，识别出系统事件（系统操作），（并写出契约的后置条件）；为每个系统事件画顺序图，为对象分配职责。

[ 实验原理和步骤] 原理：

(1)在系统顺序图中，所有的系统都被当成黑盒子看待，顺序图的重点是参与者发起的跨越系统边界的事件。

(2)系统事件是由某参与者发起的指向系统的输入事件。一个事件的发生能够触发一个响应操作的执行。

(3)请仔细研究下图,考察它是如何从左边的“购买商品”用例的文字描述中分解出3 个系统事件的。

（4）参照用例模型和概念模型，为每个系统操作估计后置条件。（实例创建、形成关联、属性修改）（5）按照设计模式为对象分配职责。

步骤：

（1）分析首选用例的文字描述，按事件进行分解，识别出系统事件。（下面以“企业综合信息管理系统”-> “进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”主线中的“收款单处理”用例为例）。

我们暂不考虑批处理。第一个核对，因为要将“货款金额填写到合同中”。后置条件显然有“销售合同”的属性修改。此合同显然已经存在，不需要创建，但需要根据合同编号find，然后形成关联。第二个核对需要根据合同明细到仓库的“存货明细”（概念模型中还没有）中去查。此核对发生前虽然敲了一下键盘，但随后并没有新的消息穿越系统边界，因此这仍然是同一个系统事件。先考虑成功场景，应该向库存系统发提货单（概念模型中还没有）就结束了。后续的削减库存（核销）、预警显然不是销售管理员的职权，并且真正的核销必须由仓库的发货人执行，才能保证货帐一致。并且“生产厂家”与“邮购公司”的运作方式不同，后者是自己的员工取货并邮寄，而前者还有可能是来人来车取货，这时仓库收到取货单后并不能立即自动处理（开发货单），必须等取货人到达才能处理。

根据题意，本项目应该是“生产厂家”模式。这又存在一个问题，如

果在开出提货单后不修改库存，可能影响并发用户和后续付款单的处理。所以有必要设计一个“临时存货明细”（概念模型中还没有）（不是真实的“存货明细”）供修改，何时按存货明细”进行刷新应该是库存管理系统的事（比如每天夜里刷新，但因为雨雪天气，取货 人迟迟不提货，是提货单作废（相当于退回销售系统，付款单变为未处理）还是就强行刷新（此时有冲突危险）？）失败场景。向“生产调度部门”发送“产品生产申请单”。如果是专门为此单进行生产，那么还应该有库存系统发来的“产品入库通知处理”用例来调用本用例进行发货。本题显然一概根据付款单运作，因此如果失败，就不处 理付款单，但按日期把它排在待处理付款单的前面。从前面的分析来看，就一个系统事件，我们就命名为“付款单处理(pb:付款单)”（2）为每个系统事件估计后置条件。(以上已做了部分分析)（3）按设计模式进行设计。

首先考虑控制者,领域控制者选参与者角色，即“销售人员”。为了避免使用FORM,窗口等表示层对象,我们人造一 个类”应用协调者”向控制者发送消息。

[ 实验结果]

① 对重点实验结果进行分析；

② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。

③ 收获与体会：事件分解的要点；控制者选择的要点；绘制顺序图的要点。

[ 实验总结] ① 对重点实验结果进行分析；

② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。

③ 收获与体会：事件分解的要点；控制者选择的要点；绘制顺序图的要点。

实验4 设计建模（2）

[ 实验日期] 2011年5月27日 [ 实验目的](1)理解面向对象类之间关联关系的概念(2)了解和掌握分析类之间的关联关系的方法

(3)了解和掌握待开发系统中类之间关联关系的分析方法(4)完善设计类图，掌握使用ROSE 对关联进行建模的过程

[ 实验内容] 根据设计建模（1）中的交互分析，进一步设计关联和对象可见性（补

上遗漏的关联）,完善设计类图。

[ 实验原理和步骤] 建模原理：

（1）关联关系描绘了给定类的对象个体之间的语义连接，是类与类之间的连接。关联可以分为一般关联、聚合关 联、组合关联和依赖关联等。

（2）一般关联包括一对类的二元关联及多个类之间的多元关联。

（3）聚合(Aggregation)表示整体和部分之间较强的关联关系，聚合关系的多重性大于1，则称为共享聚合。

（4）组合(Composition)关系表示整体和部分之间有比聚合关系更强的关系，它们之间是一对一的关系，即同生死共存亡，组合关系不能共享。

（5）依赖关系是一种使用关系，表现为一个对象仅仅调用了另一个对象的服务。可以使用下列的指导方针列出暂时性的关系：

(1)存在两个或两个以上的类相互之间就可能有关联。(2)类的操怍(成员函数)的参数列表里出现其他类的对象。(3)一个类包含另一个类的对象(对象成员)。(4)根据一般常识可能会出现的关联。步骤：

（1）分析已建立的设计类图和交互图，进一步设计关联和

对象可见性（补上遗漏的关联）。（下面以“企业综合 信息管理系统”-> “进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”主线中 的“收款单处理”用例为例）。

在销售管理子系统中，定义的各个类之间一般都有关系发生。销售人员和客户(大客户)共同签署销售合同，销售合同中涉及到多种可以销售的产品，合同经公司经理审查并签字后该合同才能生效，付款单需要客户付款，销售人员签发催款单向客户催缴欠款，销售人员制定销售计划，销售人员要检查督促执行期合同按合同执行、履 约，履约后的合同转到履约合同数据库存档备查等等。例如：

（a）销售人员与客户：一般关联，多对多

（b）销售合同与合同明细，销售计划与计划明细：组合。（c）付款单与客户：依赖关系。《如果付款单类中有“统计付款金额(客户类客户对象)”操作的话，付款 单类就依赖客户类》（2）完善设计类图 画图原理：

（1）关联关系描绘了给定类的对象个体之间的语义连接，是类与类之间的连接。关联可以分为一般关联、聚合关 联、组合关联和依赖关联等。

（2）一般关联包括一对类的二元关联及多个类之间的多元关联。

（3）聚合(Aggregation)表示整体和部分之间较强的关联关系，聚合关系的多重性大于1，则称为共享聚合。

（4）组合(Composition)关系表示整体和部分之间有比聚合关系更强的关系，它们之间是一对一的关系，即同生死共存亡，组合关系不能共享。

（5）依赖关系是一种使用关系，表现为一个对象仅仅调用了另一个对象的服务。步骤：

（1）在关联和对象可见性分析的基础上，补充一般关联、组合，泛化、依赖

（a）一般关联关系要注意关联的命名以及哪个是role A 哪个是role B。

(b)一般关联选中role B detail 中的aggregate，就变成聚合；再选中by value 就变成组合。(c)依赖画虚线箭头。（2）完善设计类图

[实验结果] ① 对重点实验结果进行分析；

② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。

③ 收获与体会：分析依赖关系的要点，绘制关联的要点。通过实验了解UML的建模的步骤和方法，了解用例图和类图等的画法，了解系统的分析和建模方法。增加动手和思维能力，使自己更加的了解软件系统前期开发的软件定义和分析方法。