——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 的（没有返回值）。向调用者返回数据的查询，这种方法没有副作用，不会永久性的改变任何对象的状态。 一个方法不应该同时属于以上两种类型。
因篇幅问题不能全部显示，请点此查看更多更全内容