BlogJava-我思故我强-文章分类-软件设计

SSH中 struts hibernate spring 各起什么作用?

李云泽 — Fri, 29 Feb 2008 07:19:00 GMT

简单的说：

struts 控制用的

hibernate 操作数据库的

spring 用解耦的
详细的说：

STRUTS 在 SSH 框架中起控制的作用 , 其核心是 Controller, 即 ActionServlet, 而 ActionServlet 的核心就是 Struts-confi g.xml. 主要控制逻辑关系的处理 .

hibernate 是数据持久化层 , 是一种新的对象、关系的映射工具 , 提供了从 Java 类到数据表的映射，也提供了数据查询和恢复等机制 , 大大减少数据访问的复杂度。把对数据库的直接操作 , 转换为对持久对象的操作 .

SPRING 是一个轻量级的控制反转 (IoC) 和面向切面 (AOP) 的容器框架 , 面向接口的编程 , 由容器控制程序之间的（依赖）关系，而非传统实现中，由程序代码直接操控。这也就是所谓 “ 控制反转 ” 的概念所在：（依赖）控制权由应用代码中转到了外部容器，控制权的转移，是所谓反转。依赖注入，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中
起到的主要作用是解耦

Struts 、 spring 、 Hibernate 在各层的作用

1 ） struts 负责 web 层 .

ActionFormBean 接收网页中表单提交的数据，然后通过 Action 进行处理，再 Forward 到对应的网页。

在 struts-config.xml 中定义 , ActionServlet 会加载。

2 ） spring 负责业务层管理，即 Service （或 Manager).

1 ． service 为 action 提供统计的调用接口，封装持久层的 DAO.

2 ．可以写一些自己的业务方法。

3 ．统一的 javabean 管理方法

4 ．声明式事务管理

5. 集成 Hiberante

3 ） Hiberante ，负责持久化层，完成数据库的 crud 操作

hibernate 为持久层，提供 OR/Mapping 。

它有一组 .hbm.xml 文件和 POJO, 是跟数据库中的表相对应的。然后定义 DAO ，这些是跟数据库打交道的类，它们会使用 PO 。

在 struts+spring+hibernate 的系统中，

对象的调用流程是： jsp-> Action － > Service ->DAO ->Hibernate 。

数据的流向是 ActionFormBean 接受用户的数据， Action 将数据从 ActionFromBean 中取出，封装成 VO 或 PO,

再调用业务层的 Bean 类，完成各种业务处理后再 forward 。而业务层 Bean 收到这个 PO 对象之后，会调用 DAO 接口方法，进行持久化操作。

李云泽 2008-02-29 15:19 发表评论

javadoc文档注释

李云泽 — Tue, 08 Jan 2008 07:49:00 GMT

对于Java语言，最体贴的一项设计就是它并没有打算让人们为了写程序而写程序——人们也需要考虑程序的文档化问题。对于程序的文档化，最大的问题莫过于对文档的维护。若文档与代码分离，那么每次改变代码后都要改变文档，这无疑会变成相当麻烦的一件事情。解决的方法看起来似乎很简单：将代码同文档“链接”起来。为达到这个目的，最简单的方法是将所有内容都置于同一个文件。然而，为使一切都整齐划一，还必须使用一种特殊的注释语法，以便标记出特殊的文档；另外还需要一个工具，用于提取这些注释，并按有价值的形式将其展现出来。这些都是Java必须做到的。
用于提取注释的工具叫作javadoc。它采用了部分来自Java编译器的技术，查找我们置入程序的特殊注释标记。它不仅提取由这些标记指示的信息，也将毗邻注释的类名或方法名提取出来。这样一来，我们就可用最轻的工作量，生成十分专业的程序文档。
javadoc输出的是一个HTML文件，可用自己的Web浏览器查看。该工具允许我们创建和管理单个源文件，并生动生成有用的文档。由于有了jvadoc，所以我们能够用标准的方法创建文档。而且由于它非常方便，所以我们能轻松获得所有Java库的文档。

2 具体语法
所有javadoc命令都只能出现于“/**”注释中。但和平常一样，注释结束于一个“*/”。主要通过两种方式来使用javadoc：嵌入的HTML，或使用“文档标记”。其中，“文档标记”（Doc tags）是一些以“@”开头的命令，置于注释行的起始处（但前导的“*”会被忽略）。
有三种类型的注释文档，它们对应于位于注释后面的元素：类、变量或者方法。也就是说，一个类注释正好位于一个类定义之前；变量注释正好位于变量定义之前；而一个方法定义正好位于一个方法定义的前面。如下面这个简单的例子所示：

/** 一个类注释 */
public class docTest {
/** 一个变量注释 */
public int i;
/** 一个方法注释 */
public void f() {}
}

注意javadoc只能为public（公共）和protected（受保护）成员处理注释文档。“private”（私有）和“友好”（详见5章）成员的注释会被忽略，我们看不到任何输出（也可以用-private标记包括private成员）。这样做是有道理的，因为只有public和protected成员才可在文件之外使用，这是客户程序员的希望。然而，所有类注释都会包含到输出结果里。
上述代码的输出是一个HTML文件，它与其他Java文档具有相同的标准格式。因此，用户会非常熟悉这种格式，可在您设计的类中方便地“漫游”。设计程序时，请务必考虑输入上述代码，用javadoc处理一下，观看最终HTML文件的效果如何。

3 嵌入HTML
javadoc将HTML命令传递给最终生成的HTML文档。这便使我们能够充分利用HTML的巨大威力。当然，我们的最终动机是格式化代码，不是为了哗众取宠。下面列出一个例子：

/**
*
* System.out.println(new Date());
*

亦可象在其他Web文档里那样运用HTML，对普通文本进行格式化，使其更具条理、更加美观：
/**
* 您甚至可以插入一个列表：
*

*
项目一
*
项目二
*
项目三
*

注意在文档注释中，位于一行最开头的星号会被javadoc丢弃。同时丢弃的还有前导空格。javadoc会对所有内容进行格式化，使其与标准的文档外观相符。不要将
或

这样的标题当作嵌入HTML使用，因为javadoc会插入自己的标题，我们给出的标题会与之冲撞。
所有类型的注释文档——类、变量和方法——都支持嵌入HTML。

4 @see：引用其他类
所有三种类型的注释文档都可包含@see标记，它允许我们引用其他类里的文档。对于这个标记，javadoc会生成相应的HTML，将其直接链接到其他文档。格式如下：

@see 类名
@see 完整类名
@see 完整类名
每一格式都会在生成的文档里自动加入一个超链接的“See Also”（参见）条目。注意javadoc不会检查我们指定的超链接，不会验证它们是否有效。

5 类文档标记
随同嵌入HTML和@see引用，类文档还可以包括用于版本信息以及作者姓名的标记。类文档亦可用于“接口”目的（本书后面会详细解释）。

1. @version
格式如下：
@version 版本信息
其中，“版本信息”代表任何适合作为版本说明的资料。若在javadoc命令行使用了“-version”标记，就会从生成的HTML文档里提取出版本信息。

2. @author
格式如下：
@author 作者信息
其中，“作者信息”包括您的姓名、电子函件地址或者其他任何适宜的资料。若在javadoc命令行使用了“-author”标记，就会专门从生成的HTML文档里提取出作者信息。
可为一系列作者使用多个这样的标记，但它们必须连续放置。全部作者信息会一起存入最终HTML代码的单独一个段落里。

6 变量文档标记
变量文档只能包括嵌入的HTML以及@see引用。

7 方法文档标记
除嵌入HTML和@see引用之外，方法还允许使用针对参数、返回值以及违例的文档标记。

1. @param
格式如下：
@param 参数名说明
其中，“参数名”是指参数列表内的标识符，而“说明”代表一些可延续到后续行内的说明文字。一旦遇到一个新文档标记，就认为前一个说明结束。可使用任意数量的说明，每个参数一个。

2. @return
格式如下：
@return 说明
其中，“说明”是指返回值的含义。它可延续到后面的行内。

3. @exception
有关“违例”（Exception）的详细情况，我们会在第9章讲述。简言之，它们是一些特殊的对象，若某个方法失败，就可将它们“扔出”对象。调用一个方法时，尽管只有一个违例对象出现，但一些特殊的方法也许能产生任意数量的、不同类型的违例。所有这些违例都需要说明。所以，违例标记的格式如下：
@exception 完整类名说明
其中，“完整类名”明确指定了一个违例类的名字，它是在其他某个地方定义好的。而“说明”（同样可以延续到下面的行）告诉我们为什么这种特殊类型的违例会在方法调用中出现。

4. @deprecated
这是Java 1.1的新特性。该标记用于指出一些旧功能已由改进过的新功能取代。该标记的作用是建议用户不必再使用一种特定的功能，因为未来改版时可能摒弃这一功能。若将一个方法标记为@deprecated，则使用该方法时会收到编译器的警告。

李云泽 2008-01-08 15:49 发表评论

如何从开发人员走向架构师

李云泽 — Thu, 20 Sep 2007 12:23:00 GMT

很多架构师都是从好的开发人员逐步过渡而来的，但并非每个好的开发人员都希望成为架构师，而且他们并不是都适合做架构师。无论您是打算进行职业转型的开发人员，还是寻找能承担体系结构设计责任的合适人选的经理，都务必对此转型过程有个清楚的了解。本文将讨论从实现专家到架构师的过渡过程。

　　在寻找优秀的指挥的时候，您首先要找的是一名优秀的音乐演奏家。但并非每个音乐演奏家都能成为优秀的指挥。架构师的专业发展方面也与此类似。越来越多的 IT 组织开始认识到良好软件体系结构的重要性，架构师职业正迅速发展为 IT 内一个独立的门类。由于要从相当小的候选范围内招募架构师，因此这就给管理带来了一些新挑战。即使人力资源部门找到了候选者，针对经验进行的筛选也比其他门类更为严格。跨越这些障碍的最快方式是要认识到，大部分好的架构师同时也是好的开发人员，因此寻找架构师人才时可能首先应该从普通开发人员中找起。招聘人员在对候选者(内部或外部)进行详细审查时，应该考虑这个观点。不过，对此资源进行挑选可能比较麻烦，因为只有极少的优秀开发人员具有成为架构师的特征或愿望。

　　本文列出了开发人员成为架构师要进行的工作。我将从可能考虑进行此转型的开发人员和评估进行此转型的开发人员的经理这两个方面来探讨这一问题。我还将提供一系列在做出这些决策时要考虑的因素。

　　个人特征

　　软件开发团队和管理层之间的联系始终是 IT 中的一个关键所在。二者都倾向于以完全不同的方式考虑给定的问题。大部分相关技术都是讨论项目经理应如何跟踪和解释开发人员的进度和问题。但沟通不足的情况仍然非常普遍，而且这是项目失败的首要原因。好的架构师是解决这个问题的最有效办法。架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应，以确保成功。以下是成功架构师的一些主要特征。

　　愿意并有能力进行沟通：在开发人员中发现架构师的最有价值标准是有效的沟通。您需要技术娴熟、经验丰富的开发人员，这样的人员需要有就项目中的业务相关问题进行沟通的经历。架构师经常必须对理解方面的差距进行预计，然后才能有所贡献。他们必须愿意克服困难来确保技术和业务观点的融合。他们并不必对意见交换工作进行计划和协调;这仍然主要是项目经理的工作。他们的任务是确定表述系统设计时的最佳工具和构件，以促进有效的意见交换。他们必须能够判断当前方法显得不足而需要采用新方法的情况。写作技能也非常重要，还需要具有制作草图的技能或使用制图软件的能力。

　　具有处理谈判细节方面的经验：架构师经常需要负责讨论系统开发的技术折衷方案。优先级的冲突可能会带来实践限制、风险规避或可能导致在各个不同业务组之间需求不同。优秀的架构师能够有效地评估技术可能性，并能在不损失项目的主要价值的前提下制订开发计划来处理各种利害关系和限制。这与前面讨论的沟通技能紧密相关，但同时也要体现架构师的技术能力。好的架构师候选者应该是经常帮助对有争议的讨论进行引导的人，能够使讨论得出新的想法，而不会使其在一个位置停滞不前。

　　自觉主动;积极解决设计问题：架构师的日常工作目标经常并不明确。很多开发人员直接参考功能规范来列出任务清单。架构师通常则是向这些开发人员提供所需结构的人员，以便尽可能提高工作效率。好的候选者不仅进行沟通方面的工作，而且也会预计各种设计问题并加以解决——通常在没有任何具体指示的情况下自觉进行。无论所分配的职责如何，积极参与项目的开发人员都有机会从一起工作的人员中脱颖而出。

　　抽象思维和分析：架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。他们必须能够理解抽象概念，并以具体的语言对其进行沟通。开发人员中好的候选者经常要求或自己主动解释开发生命周期中容易混淆的问题。他们能迅速评估各种想法并将其纳入后续工作的操作建议中。

　　开发人员经常具有很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。管理人员经常说开发人员具有“工程意识”，而这是一个用于评估架构师的非常有意义的方面。架构师应该具有很强的解决技术问题的能力，但还必须能够准确获知更为全面的人员如何与技术交互的信息。这要求具有某种形式的抽象思维(而不再是代码的细节)，这种思维能力可能较难形成。

　　有些人认为，某种级别的正式教育是成为优秀开发人员的必备条件之一，我并不同意这种精英论。我遇到了很多高中就辍学的优秀开发人员。不过，对于体系结构设计工作，我的个人经验以及我对所需能力的认识都让我相信，好的架构师通常至少获得了一个有挑战性的学士学位。

　　跟踪生命周期

　　好的架构师通常有在具备定义良好的软件开发生命周期(Software Development Life Cycle，SDLC)的组织工作的经验。架构师必须理解在其所属专业内最重要的操作过程。这并不意味着需要有其他前提，例如，并不需要高能力成熟度模型(Capability Maturity Model，CMM)级别的工作经验。好的架构师可能来自使用 SDLC 的多个小型迭代的极限编程(Extreme Programming，XP)方法的组织。务必注意各种传统软件开发操作，如 Michael A. Jackson 的方法：Jackson 结构编程(Jackson Structured Programming，JSP)和 Jackson 系统开发(Jackson System Development，JSD)。Jackson 的研究对架构师职业发展的意义就像 Donald Knuth 的研究对程序员一样重要。架构师可以偏爱任何经典的、经过时间考验的软件系统开发方法。

　　SDLC 也可以成为评估架构师合适人选的有用机制。每个 SDLC 阶段都具有能提供相关线索的特征。SDLC 包含很多小的变体，但在此部分，我将使用几乎所有方法的公共基础部分。下面的列表详细说明了 SDLC 的各个阶段，并列出了好的架构师候选者在每个阶段表现出来的特征。

　　分析：在分析期间，好的架构师会考虑非技术影响，以便了解需求和将在其中进行开发的环境。架构师可为风险评估任务带来广泛的软件经验供参考。寻找具有丰富经验的开发人员，以帮助业务部门理解技术人员正确解释需求所需的信息。寻找在开发的早期阶段能够预计可能遇到的问题的开发人员。
　　设计：在高级设计期间，好的架构师会收集问题空间的各个抽象元素，并就其进行沟通，以便开发团队草拟将要开发的系统的相关图表。架构师负责将需求谨慎地映射到所得到的系统体系结构的功能。在详细设计期间，他们所扮演的角色并不是核心角色，但为了根据整个系统的规则对特定模块的元素进行审查，仍然需要他们。寻找善于让团队能够预计设计决策对最终系统的影响的开发人员。寻找善于确定一些最佳构件来促进与技术和非技术受众沟通设计问题的开发人员。
　　实现：在实现期间，架构师对项目进行引导，以确保其符合系统体系结构。他们在一线评估技术更改请求，并确定如何对设计进行调整，以最好地处理此类请求。架构师还要密切了解开发人员的进度，特别要跟踪系统中模块间的集成点的状态。寻找经常对讨论进行引导来连接多个子系统的开发人员。寻找项目经理可以依赖其快速地进行与更改和出现的问题相关的风险评估的开发人员。
　　测试：架构师对系统集成和用户接受度测试进行指导，并负责评估进度的正确沟通的持续测试结果。寻找理解错误模式且善于将测试复查结果转换为行动计划的开发人员。
　　维护：在维护期间，架构师将发起关于系统集成的讨论。无论处理 IT 基础设施问题，还是确保部门之间的技术合作，架构师都必须完全理解应用程序，必须快速学习姊妹应用程序的体系结构，而且必须就集成点和风险进行有效沟通。寻找具有系统集成经验且表现出快速掌握全貌的能力的开发人员。系统集成是一项独特的任务。

　　架构师培养建议

　　有些组织能比其他组织更有效地进行架构师培养。如果充分考虑到招聘此类新专业人才的困难，努力促成能鼓励开发人员发展为架构师的环境是非常明智的策略。但务必避免对不愿意或不适合走这条路的开发人员进行处罚。组织应该为开发人员制订多条发展路线，包括那些愿意继续担任开发人员的人。对架构师而言，资深开发人员不可或缺。他们可以实现系统中最关键的模块。通过对其他开发人员进行代码检查和测试支持，他们可帮助确保总体软件质量，而如果质量不能保证，即使最好的体系结构也毫无用处。

　　组织应制订个人评估程序，以鼓励开发人员考虑其职业目标，其中要包含体系结构设计的选项。应该鼓励经理在其下属中寻找体系结构设计人才。应该实现指导计划，让架构师与希望成为架构师的开发人员协作工作。应该鼓励开发人员通过参加各种协会、撰写文章和参加会议，从而参与到专业领域中来。通过这样参与进来，可帮助开发人员从新的角度理解系统，并帮助他们更好地就其认识进行沟通。这样还能培养可提高效率的重要创新想法。

　　结束语

　　开发人员一旦迈出了通向体系结构设计专业方向的第一步，就可以利用很多资源来获得帮助，其中包括很多来自 IBM 的资源。有时候，此过程的最困难的部分就是第一步，而本文提供了一些线索和提示，经理和开发人员可以利用其来评估应该鼓励哪些人努力成为架构师。

李云泽 2007-09-20 20:23 发表评论

[转]UML学习笔记（二）：运用面向对象思想

李云泽 — Thu, 20 Sep 2007 11:43:00 GMT

[转]UML学习笔记（二）：运用面向对象思想

关键字: UML学习笔记

面向对象是一个依赖于几个基本原则的思想库。

对象是类的实例。

类是具有相同属性和操作的一类对象集。

继承是面向对象中的一个重要方面。对象继承了所属类的属性和操作。类同样也可以继承其他类的属性和操作。

多态性是另一个重要的方面它是指不同的类中可以有相同名字的操作，并且这个操作在每个类中都能以各自不同的方式执行。

对象对其他对象和外部世界隐藏了其操作的执行过程。每个对象都要提供一个让其他对象用来执行该对象中操作的接口。

对象通过相互之间的消息传递协同工作。消息是执行操作的请求。

对象通常要和其他对象发生关联。关联可以具有多种形式。一个类的对象可能和多个其它类的对象同时发生关联。

聚集是关联的一种，聚集对象由部分对象组成。组成又是一种特殊的聚集。在一个组成对象中，部分对象只能作为组成对象的一部分与组成对象同时存在。

类的可视化表示

如果WashingMachine(洗衣机)类是Household Appliances(家用电器)包的一部分，那么这个类的名字为：Household Appliances::WashingMachine。包名在左，类名在右，中间用双冒号隔开。这种类型的类名叫：路径名(pathname)。

属性

单字属性名小写。如果属性名包含了多个字，这些字要合并，并且除了第一个字外其余字首字母要大写。

对象名首字母小写，后面跟一个冒号，冒号后面是该对象所属的类名，并且整个名字要带下划线。

命名实例：myWasher:WashingMachine

匿名实例：WashingMachine

例：类的属性在该类的对象中都有具体值

例：属性可以带类型和缺省值

操作

单字操作名小写。如果操作名包含了多个字，这些字要合并，并且除了第一个字外其余字首字母要大写。

在操作名后面的括号中可以说明操作所需要的参数和参数的类型。有一种操作较函数(function)，它在完成操作后要返回一个返回值。可是指明函数的返回值及返回值的类型。上述全部的操作信息被称为操作的型构。

例：操作的型构

属性、操作和可视化表达

有时，只显示类的一部分属性和操作很有用。为了说明你只表示出部分操作和属性，可以在列表的后面加上3个小点“…”。这个符号叫省略符，这种省略了一个或多个属性或者操作的表示法叫做类的省略表示法。

如果属性或者操作列表太长，可以用构造型来组织属性或操作列表，以方便理解。构造型是UML提供的扩展机制：它允许你创建新的模型元素以解决具体问题。构造型用双尖角括号括住的名字来表示。

例：省略符号说明还有没列出来的属性或操作

例：可以使用构造型来组织属性和操作列表

职责和约束

职责描述了类做什么——也就是类的属性和操作能完成什么任务。

这里的想法是要有足够的信息以非二义性的方法去描述一个类。说明类的职责是消除二义性的一种非形式化的方法。

更形式化的方法是使用约束，它是一个用花括号括起来的自由格式的文本。括号中的文本指定了该类所要满足的一个或者多个规则。

例：在类图标中，操作列表区域的下面区域可以写类的职责

例：用花括号括起来的规则表达式限制了洗衣机的容量之只能三者选一

附加注释

李云泽 2007-09-20 19:43 发表评论

[转]UML学习笔记（一）：UML简介

李云泽 — Thu, 20 Sep 2007 11:41:00 GMT

[转]UML学习笔记（一）：UML简介

关键字: UML学习笔记

统一建模语言（ Unified Modeling Language ， UML ）

一些术语：

系统（ system ）指的是硬件和软件的结合体，它能提供业务问题的解决方案。

系统开发（ system development ）是为客户建立一个系统的过程。

客户（ client ）是需要解决问题的人。

系统分析员（ analyst ）将客户所要解决的问题编制成文档，并将该文档转交给开发人员。

开发人员（ developer ）是为了及决客户的问题而构造软件并在计算机硬件上实施该软件的程序员。

UML 的组成

UML 包括了一些可以相互组合图表的图形元素。

1 ．类图

一个类（ class ）是一类或一组具有类似属性和共同行为的事物。

矩形方框代表类的图标，它被分成 3 个区域。最上面的区域中是类名，中间区域是类的属性，最下面区域里列的是类的操作。

举一个例子，属于洗衣机（ washing machine ）类的事物都具有诸如品牌（ brand name ）、型号（ model name ）、序列号（ serial number ）和容量（ capacity ）等属性。这类事物的行为包括“加衣物（ add clothes ）”、“加洗涤剂（ add detergent ）”、“开机（ turn on ）”和“取出衣物（ remove clothes ）”等操作。

2 ．对象图

对象（ object ）是一个类的实例，是具有具体属性值和行为的一个具体事物。例如，洗衣机的品牌可能是“ Laundatorium ”，型号为“ Washmeister ”，序列号为“ GL57774 ”，一次最多可以洗涤重量为 16 磅的衣物。

对象的图标也是一个矩形，和类的图标一样，但是对象名下面要带下划线。具体实例的名字位于冒号的左边而该实例所属的类名位于冒号的右边。

3 ．用例图

用例（ use case ）是从用户的观点对系统行为的一个描述。

例，一个人使用一台洗衣机，显然是为了洗衣服（ wash clothes ）。

代表洗衣机用户的智力小人形被称为参与者（ actor ）。椭圆形代表用例。

参与者（它是发起用例的实体）可以是一个人也可以是另一个系统。

4 ．状态图

一台洗衣机可以处于浸泡（ soak ）、洗涤（ Wash ）、漂洗（ Rinse ）、脱水（ Spin ）或者关机（ off ）状态。

最顶端的符号代表起始状态，最底端的符号表示终止状态。

5 ．顺序图

类图和对象图标大的实系统的静态结构。在一个运行的系统中，对象之间要发生交互，并且这些交互要经历一定的时间。 UML 顺序图所表达的正式这种基于时间的动态交互。

例，洗衣机的构件包括一个注水的进水管（ Water Pipe ）、一个用来装衣物的洗涤缸（ Drum ）以一个排水管（ Drain ）。假设已经完成了“加衣物”、“加洗涤剂”和“开机”操作。洗衣服这个用例被执行时按照如下顺序进行：

1 通过进水管想洗涤缸中注水。

2 洗涤缸保持 5 分钟静止状态。

3 水注满，停止注水。

4 洗涤缸往返旋转 15 分钟。

5 通过排水管排掉洗涤后的脏水。

6 重新开始注水。

7 洗涤缸继续往返旋转洗涤。

8 停止向洗衣机中注水。

9 通过排水管排掉漂洗衣物的水。

10 洗涤缸加快速度单方向旋转 5 分钟。

11 洗涤缸停止旋转，洗衣过程结束。

图中，对象之间发送的消息有：注入新水（ Send fresh water ）、保持静止（ Remain stationary ）、停止注水（ Stop ）、往返旋转（ Ratate back and forth ）、排掉洗涤后的脏水（ Send soapy water ）、排掉漂洗过的水（ Send rinse water ）等。

6 ．活动图

用例和对象的行为中的各个活动之间通常具有时间顺序。

7 ．协作图

系统的工作目标是由系统中各组成元素相互协作完成的。例子中洗衣机构件的类集中又增加了一个内部计时器（ Internal Timer ）。在经过一段时间后，定时器停止注水，然后启动洗涤缸往返旋转。图中的序号代表命令消息的发送顺序。

8 ．构件图

构件图和部署图和整个计算机系统密切相关。

9 ．部署图

UML 部署图显示了基于计算机系统的物理体系结构。它可以描述计算机和设备，展示它们之间的连接，以及驻留在每台机器中的软件。每台计算机用一个立方体来表示，立方体之间的连线表示这些计算机之间的通信关系。

如果需要将图中的组织元素分组，或者在图中说明一些类或构件是某个特定子系统的一部分，可以通过将这些元素组织成包（ package ）来达到此目的。包用一边突起的公文夹形图标来表示。

注释（ note ）的图标是一个带折角的矩形，矩形框中是解释性文字。注释和被注释的图元素之间用一条虚线连接。

构造型（ stereotype ）能够使用现有的 UML 元素来定制新的元素。构造型用尖对括号括起来的一个名称来表示，这个括号叫双尖括号（ guillemets ）。

李云泽 2007-09-20 19:41 发表评论