ulark的专栏

 用例图描述了系统提供的一个功能单元，帮助开发团队以一种可视化的方式来理解系统的功能需求。用例图包含的元素有： 动作者（actor）、用例、关系。1.   动作者（actor）：系统用户能扮演的角色（role）。这些用户可能是人，可能是其他的计算机，一些硬件，或者甚至是其它软件系统。唯一的标准是它们必须要在被划分进用例的系统部分以外它们必须能刺激系统部分并接收返回。（使用系统的用户或者和本系统

  理智的战士从来不会赤手空拳上战场杀敌，那样的做法是用鸡蛋碰石头，结果只能是"壮志未酬身先死"。如果把建模比作敌人，那么我们知道很多热血的软件开发人士就败在这个敌人的手上。一个原因就是太过于鲁莽，在不知道建模为何物的时候就开始了战斗。一、什么是建模？俗话说："横看成岭侧成峰"，说得是从不同角度观察同样一座山峰，会呈现不同的景象。其实建模可以这样理解：从某个特定视角对软件系统的一次观察。

理智的战士从来不会赤手空拳上战场杀敌，那样的做法是用鸡蛋碰石头，结果只能是"壮志未酬身先死"。如果把建模比作敌人，那么我们知道很多热血的软件开发人士就败在这个敌人的手上。一个原因就是太过于鲁莽，在不知道建模为何物的时候就开始了战斗。一、什么是建模？俗话说："横看成岭侧成峰"，说得是从不同角度观察同样一座山峰，会呈现不同的景象。其实建模可以这样理解：从某个特定视角对软件系统的一次观察。同

UML的信任危机有一次我在做这个课程培训时，有位同学跟我说，他曾经听过不少UML培训，以为UML培训就是这个样子，没想到我的课程让他大开眼界，重新认识了UML！他对课程的赞美让我非常高兴，但目前业内UML面临着比较普遍的信任危机，批评UML、认为UML用处不大的文章随处可见，这让我十分担忧。我读书时从来没有听说过UML这回事，仅是在工作后才开始学习。很多书籍将UML讲得过于复杂、过于理论化，其实完

http://blog.youkuaiyun.com/sdlcgxcqx/archive/2009/05/22/4209769.aspx 前些时间参加了潘加宇老师的技术讲座，UML建模技术受益匪浅。我也把平时的一些积累和上次的收获总结在这篇文章中，主要讲解用例图相关的知识。      用 例图是软件需求分析到最终实现的第一步，它描述用户如何使用系统及使用系统什么样的功能。用例图从业务角度上体现谁来使用系统

   用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结

这是一堂关于UML基础知识的补习课；现在我们做项目时间都太紧了，基本上都没有做过真正的class级别的详细设计，更别提使用UML来实现规范建模了；本篇主要就以前自己一直感觉很迷糊的几种class之间的关系进行整理，让我们在真正用UML进行比如类图设计时能够更加清晰明了；以下就分别介绍这几种关系：继承指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己

 序列图主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。很象类图，开发者一般认为序列图只对他们有意义。然而，一个组织的业务人员会发现，序列图显示不同的业务对象如何交互，对于交流当前业务如何进行很有用。除记录组织的当前事件外，一个业务级的序列图能被当作一个需求文件使用，为实现一个未来系统传递需求。在项目的需求阶段，分析师能通过提供一个更加正式层次的表达，把用例带入下一层次。那种情况下，用例

注：本文为IBM Developer网站UML2.X系列教程的学习笔记，原文参见：http://www.ibm.com/developerworks/cn/rational/r-uml/一、UML中基本的图范畴：在 UML 2 中有二种基本的图范畴：结构图和行为图。每个 UML 图都属于这二个图范畴。结构图的目的是显示建模系统的静态结构。它们包括类，组件和（或）对象图。另一方面，行为图显示系统中的