分享个UML基础教程 的资料..不知道大家有没有...

过年让我扎实地"懒散"了一阵子,回来发现自己的博客点击率已经从10万猛增到16万,感觉有些对不住关心我的网友了.接着聊年前关于MES的话题吧.年前实际上谈到的是ERP+MES+DCS这种三层信息化架构的底层DCS面对的本质需求,简单地说,就是"对操作的精确控制".所谓追求的本质需求是按如下思路进行的:因为DCS只关心的是对"自动化设备操作的精确控制"问题,所以,我们去掉对操作的实体到底是谁的关心,即到底是对"自动化设备操作",还是对"人的操作",或是"人机混合操作"的精确控制的关心,进行一般化推广,就只留下"对操作层的操作的精确控制"的需求了.在探讨MES的本质需求之前,还是先看看原来意义上的ERP的本质需求吧.这回先直接说出我的观点了:我认为ERP满...

  各类文献对MES的“承上启下”作用典型的描述如下：“MES处于企业信息系统ERP/SCM和过程控制系统DCS/PLC的中间位置。ERP作为业务管理系统，DCS/PLC作为控制系统，而MES则作为生产执行系统。MES与上层ERP等业务系统和底层DCS等生产设备控制系统一起构成企业的神经系统，一是把业务计划的指令传达到生产现场，二是将生产现场的信息及时收集、上传和处理。MES不单是面向生产现场的系统，而是作为上、下两个层次之间双方信息的传递系统，是连结现场层和经营层，改善生产经营效益的前沿系统。”。上述加重部分与我上篇中层经理角色的说法不谋而合，我认为，这句话道出了MES面对的本质需求。为了更直观形象地理解这话的含义， 我整理了下面的图形：  以上谈到的，依然是以大型制造企业为场景的MES本质需求的概念，是ERP+MES+...

我很奇怪,这里的人好象很关注ARIS,但对UML似乎不怎么关注,不知道是什么原因.发起这个讨论,看是否对唤起大家对UML的重视有没有用.ARIS和UML是什么关系呢?在ARIS的中文培训教程中,我看到了关于ARIS和UML的介绍.似乎谈到如下含义:1.ARIS中可以集成UML的表示方法;2.ARIS的各种视图可以和UML的某些视图产生对应关系.不知道我的上述理解是否正确,请这里的ARIS专家指正.如果上面的理解没有大的偏差,我的疑问就来了:如果UML只是一种表达工具,ARIS是一个体系结构,那么,ARIS这个体系结构当然可以用UML来部分或全部表达.从ARIS自身的论述来看,认为,UML只能部分表达ARIS的视图.从UML作为一种通用的表达工具来说,它是一个足够小的相对完整的语义集,应该可以用来表达大部分的体系结构?这样就出来疑问1:1.UML是否可以用来完整地表达ARIS的内容,而不需要...

最近看到有圈友学习RUP时对众多的模型感到困惑,推荐一篇以前的旧作供参考.....我发现对对学习UML建模影响最大的问题，是没有建立清晰的描述各种模型的参照系。各种各样名称的模型东一个西一个，就像我小孩的玩具一样随意丢放，随意就拿来玩弄。必须把模型摆放整齐。软件的模型到底有哪些？它们到底有什么作用？我们必须把存放他们格子画好，然后一个一个把他们放进去。而且，大家的格子还应该统一，否则，各自有理，拿以为是对同一个对象，实际不是对同一个对象的不同见解互相讨论。大家都急于求成，忘记在讨论之前交换相互的格子，看看是否一致。软件模型参照系：参照系是一组坐标系，它描述的是一个空间，在这个空间中将摆放一些认识对象。我们把认识对象在空间中找到自己特定的位置，就不会导致认识的冲突，对对象关系的描述才变得确定。.......

本项目商业模式简单的业务模型 上面的文字阐述了项目基本的商业模式和业务前景，相信作为一个“电梯演讲”已经可以小小地吸引投资人的注意了，前文所讲述的商业模式用UML业务模型也可以得到更清晰的表达。 本来本项目有了上面的文字和图形描述，已经将业务服务体系讲得比较清晰了，已经没有必要专门建立UML业务模型了，但是为了让读者能对比区分认识业务模型和系统模型，这里还是简单地将本项目的业务模型例讲如下：（请注意，我在业务模型之前加的定语是“本项目的”，而不是“本系统的”，假设你在某些文档中看到了“本系统的业务模型”这样的文字的话，那么，你就可以怀疑那个模型的作者是否能够或认为有必要清晰地区分业务模型和系统模型了，而我，是极力推荐区分这两个模型的）。业务用例模型 以往的翻译服务“成行不成市&...

业务用例实现       “业务用例实现”是一个名词，含义是：对某个业务用例内部执行过程的一种实现方案。对于本项目业务用例图中的“翻译任务服务”用例，用一个对应的“翻译任务服务实现”的用例实现来对应实现方案。UML图形表达如下： 在“翻译任务服务实现”之下，使用如下四个UML的顺序图，来表达这个实现的具体内容。 1．  注册受理过程 2．  任务受理过程 3．  交易撮合过程 4．  交易支持过程      上述四个顺序图，充分展现了“翻译任务服务”用例内部的一种正常状态下的实现方案，该实现方案...

从业务模型中发现问题和机会 以上的分析和设计并没有以开发目标系统为假设前提，只是提出了一种将“翻译服务”进行市场化经营运作的假想方案，并对这个假想的方案进行了并不完整的业务建模，通过用这个不完整的业务模型进行简单的演练，我们已经能发现，要在现实生活中，完成这个接近理想的运行过程，是多么的不容易，这正好可以对翻译服务之所以“成行不成市”的原因进行解释。 我们发现，翻译服务作为一种知识服务的特殊形式，和一般知识商品和普通商品的交易具有以下两个明显的区别： 1． 个性化极强 一个翻译任务，仅对特定的翻译消费有意义。也就是说，翻译任务服务是针对个体的一对一的服务，受众集中唯一。翻译产品服务这方面的特征相对较弱。一个翻译产品推出，可以面对一个消费群。这个特点，对翻译任务的撮合造成了很大的困难，如果没有合适的办法能在大量的个性化翻译任务需...

系统需求分析 系统模型是以建模者对业务中存在问题和机会已经有清楚的了解，对业务流程的目标和价值已经有了清楚地认识为前提的。在这里，“清楚”的衡量标准是：和待开发系统的相关利益者代表达成了一致的认识。如果没有这个前提条件，继续深入探讨业务模型是有必要的。在接下来的系统建模阶段，系统开发人员和来自业务上的人员如果经常就业务上的问题发生争执的话，多半就是因为前面省略了业务建模而带来的风险在兑现。 在本项目中，我们要开发的目标系统是一个基于互联网的翻译交易系统。系统的主角和各自的价值，以及在目标系统中实现各自价值的过程可以总结在下面的表格中： 主角 期待实现的价值 在目标系统中直接实现主角价值的过程 翻译消费者 V1.1 对于具体的口译任务，尽快找到合适的翻译者来执行。并在翻译...

图1。do-gnmove顶层活动图2.生成正常对局着手活动图3.查找棋盘信息活动图图4.有棋子处理内部活动图图5.无棋子处理内部活动图...

用面向对象的概念来说,岗位是业务人员的类型定义,在UML业务建模中,岗位会建模为业务系统内部的工作者(work)的定义.即:具体的业务人员是业务对象(Object),而岗位则是这种对象的"类"(Class);在面向对象中,定义一个类,需要定义这个类的很多信息.用知识管理者的说法就是要画一张岗位的知识地图.面向对象的知识表达,只是提供了一种特定的坐标系来画这个地图.首先,我们来看看,面向对象方法如何定义"类".最基本的是属性和方法.类的属性规定这种类型的对象所具备的性状特征(如玫瑰花的花瓣颜色是其本身的性状特征),以及与外部对象的关联投射在这种类型上的特征,比如:"门牌号"作为"住所"类型的一个特征,是住所和街道的关系投射到住所身上的特征.类的方法规定这种类型的对象所具备的行为能力特征(如玫瑰花能开放,能用来表达...

  基础知识第二讲:怎样对客户进行UML业务建模 简单而言，客户就是准备购买或使用、或者已经购买或使用了一个组织（下称业务系统）的产品或服务的人。对于这个描述中，站在不同的角度，对客户的实质理解可能不同，而UML业务建模，则抓住了客户的这样一个实质含义：客户是站在这个业务系统的外部，和这个业务系统发生交互行为的对象。早期有专家把Actor翻译为"外部动作者"，虽然有些拗口，但意义非常精准。为什么UML一定要站在交互行为的角度来看客户呢？这是因为一个客户的重复进行的行为能最清楚地表达客户的真实需求（即所谓肢体语言表达更丰富且真实），对客户和业务系统之间的交互行为的描述和记录，不但可以指引未来类似的过程重复进行，更本质的意义在于，这些交互行为，清楚地表达了客户和业务系统之间价值转移发生的全过程。一个业务系统是必须是一个开放的系统，也就是说，它必须接受来自外部的刺激...

...服务项目，也谈到了畅享网能提供的价值。如：同专业人士分享您在管理和信息化领域的思考、心得、经历、体验。就是对服务价值的描述，而创建个人博客，记录人生感悟、展示自我风采，用拖拉方式DIY博客，完全个性化。则是一个具体的服务项目。服务价值是通过提供服务项目来实现的。进行这样的区分是非常重要的，因为建模的关键之一就是要仔细辨识一些概念的微妙关系与区别，只有这样，我们才能真正认清事物的关键部分和本质部分。UML业务建模正是通过对服务项目的建模来体现业务系统的价值的。UML使用"业务用例"（Business Usecase）一词来称呼服务项目。很多初学者对"用例"这个名字感觉很不习惯，为什么要取这么个怪名字呢？我想，主要还是为了突出服务项目的动态交互性和价值的明确性。Usecase这个名字首先告诉我们这是一单Case，什么叫Case？Case就是当回事，当回事...

...t;一条龙"服务，就是系统性地为客户提供全方位的服务，是最大限度地提高客户的满意度的，体系化的服务。只有通过特定的客户和服务项目之间的联系，不同服务项目之间的联系，业务系统才能把不同类型的客户或供应商集结起来，这就构成了业务系统对外的服务体系。对于企业来说，只要能够对适当的客户群提供系统性的、体系化的服务，一般就都具备了长盛不衰的基础。我们已经知道，对客户和供应商等业务系统外部的交互者，UML用"业务主角"的概念来建模，对业务系统对外提供的服务项目，UML用"业务用例"的概念来建模。对上述业务系统的对外服务体系，UML则运用了最基本的模型-"业务用例模型"来表达。一个组织面对什么客户群，提供怎样的服务体系，是决定一个组织业务架构的基础。比如：供电局和环保局的业务架构就不同，学校和医院的业务架构也不同，商场和工厂的业务架构...

   前面我们从业务系统的客户谈到服务项目，从服务项目谈到对外服务体系，可以说，这些是"站在离业务系统比较远一点的地方"看到的业务系统比较宏观的外部景象。如果我们再"走近"一点，但仍然保持是"站在业务系统外面"的观察点来仔细观察一个业务系统，那么，我们就会"看到"业务系统的客户是如何享受每一个服务项目的服务的，我们可以描述客户的详细的体验过程，这是发现和评价服务项目的价值最直接的办法。 UML通过事件流描述的办法来记录（设计）客户在服务项目上的交互过程。此时，我们需要把业务系统看成是一个"黑箱"，要想象客户与业务系统的交互过程发生在"黑箱"的某个对外开放的"窗口"上，这个窗口就代表一个服务项目，我们只能看到客户以及业务系统在这个窗口...

  前面讲到对服务体系建模的时候，提到一个服务体系中最重要的部分之一就是服务项目之间的关系，这一讲开始，我们专门来探讨这个问题。在现实的业务工作中，针对一个业务系统的任意两个服务项目，要么它们之间有直接的关系，要么没有，正是因为存在服务项目之间的关系，才将一系列的服务项目整合为业务系统整体的服务形象。那么，通常的服务项目之间可能存在的关系有哪些种类呢？对这些关系UML又怎样来表达它们呢？在UML标准语义中，只提供了三种用例关系的表达方法，联系我在第三讲中讲到的服务项目的关系，对这三种用例关系的"精确解释"如下：1．    包含关系，其含义如下：l         业务主角享受一个服务项目价值时，一定会享受到另一个服务项目的价值；l  ...

      上一讲讲到我把服务项目之间的关系归为两类：一类是实关系，另一类是虚关系。服务项目之间的实关系，是服务项目实际操作过程中实实在在存在的关系，这是对业务系统建模工作本来就要表达的内容。任何一个服务项目，都是过程与目的的综合，也就是操作流与价值流的合流，通俗地说就是既“可用”又“有用”的事例，“可用”表明可操作，有操作流程，“有用”表明有价值，能达到某些目的。UML标准语义中的用例包含关系和扩展关系，正是在服务项目之间的过程关系与目的关系上，进行了两种最基本的分类表达。仔细分析包含关系和扩展关系的区别，我们会发现，两种关系是从过程的“内”与“外”，目的的“同”与&ldq...

     前面已经多次讲到，虚关系就是概念关系。对于不大习惯抽象思维的读者，可能对于什么是概念关系可能仍然不是很清楚。下面举个简单的例子来说明： 这里有两句话:1.     “客户吃了一个苹果。”2.     “苹果是水果的一种。”第一句话讲到客户和苹果之间的一个关系：客户吃苹果，这里，“苹果”一词指的是一个实在的苹果，代表苹果的实物，所以，“客户吃苹果”这个关系就是实关系：我们可以用眼睛实实在在地看到这样的关系发生；第二句话讲到苹果和水果之间的一个关系：苹果是水果的一种；这里，“苹果”一词泛指所有的苹果，代表苹果的概念，所以，“苹果是水果的...

...人简历，可以发布求职信息，并对求职信息管理。回复：简单地说,电子商务就是在网上做生意,严格地说,电子商务是现代供应链管理的重要组成部分。abel_zhyb在这里谈到的是一个简易的电子商务网站的系统.在这个系统上,对客户提供了几项简单的服务。在这里,业务建模的对象是谁,需要仔细的辨析一下。业务建模的对象从理论上讲是业务系统,比如一个企业；而不是计算机信息系统,比如一个网站。对计算机信息系统也可以进行UML建模，那本来就是UML的老本行。业务建模的过程步骤方法本来就是从系统建模引伸而来的。电子商务网站系统看起来有些特殊,似乎在网站本身的功能就代表了大部分的业务系统功能,也就是说,分析了电子商务网站,就基本上等于分析了一个经营电子商务网站的公司,比如,分析了阿里吧吧网站和贸易通等产品,就等于分析了阿里巴巴公司。果真是这样的吗?其实还是有区别的。从abel_zhyb的建模目的来说,他需要的不是一个...

...务系统内部。站在业务系统外部的观测点就是业务主角的观测点。站在业务主角的位置观测业务过程的执行步骤过程用事件流模型来表达。站在业务系统内部的观测点就是业务工人（业务岗位人...

...quot;内是更内的外".表现在建模手法上就是系统,子系统,子系统的子系统这种多层处理,将内部的问题,转化为外部的问题.这可以解决大部分的线性关系问题.难题是对系统内部的非线性关系导致的"涌现"问题的表达,这确实是一个困绕业界的大问题.我个人的理解,这个问题的解决和系统架构的设计密切相关.我甚至认为,系统架构所起到的作用,正是整合系统内部资源,涌现整体特性的关键要素.UML建模,对系统架构的表达进行了比较充分的考虑,从不同模型的不同视图的分工组合,相互联系,已经能够描绘出比较复杂的问题结构、功能结构和资源配置结构.关于岗位建模这篇文章，确实是一块“砖”，我打算在讲业务对象模型时重讲。面向对象的岗位建模，余山老师提出了动作者和动作的分离所带来的好处，我同意。从传统的面向过程的纯粹功能堆砌形成流程的观点看，面向对象将“对象&rd...

当本圈成员发展到１０人的时候，我将开始用“一个基于互连网的翻译交易系统”为例，讲解如何为信息系统建立UML模型。...

很多人总结ERP乃至其他信息系统失败的原因时,最常提到的原因莫过于信息系统与企业的实际工作软环境不相适应.于是,我们感觉似乎是要先把企业的实际工作软环境改造好,然后再实施ERP,或者双管齐下,才能见效.从业务流程重组到业务流程改进再到业务流程管理,业界下了很大的功夫,似乎最终的目标就是为了把一套ERP实施上去.于是,"业务建模"逐渐成为一个热门的话题.谈到业务建模,很多人的第一反映就是建模的理论和工具,如GRAI/GIM、IDEF、ARIS、CIMOSA、BAAN/DEM、UML等,似乎没有了这些理论、工具和方法,业务建模就无从谈起。事实上,我们每一个企业的经营者,在他经营企业的每一天,无一时刻不在进行业务建模的工作,不管他的企业是一个大型的跨国集团,还是路边的一个小卖部.每一个企业,都必然有它自己的业务模型.只是这些业务模型的存储位置,表达方式,系统性程度,规模大小各...

----为AMT<前沿论丛>供稿大纲,请笑纳.明天出初稿....

----为AMT<前沿论丛>供稿大纲,请Miss cheng 笑纳.明天出初稿....

...“业务工人”和“业务实体”，图中简要地在它们之间建立了静态的结构关系。这些业务工人和业务实体，一旦各自被分配了相应的职责，就可以通过它们之间建立的这些静态结构关系进行互通消息、互动操作，实现业务服务体系中提出的服务项目及其关系。 比如说，对业务服务体系中的“翻译交易”用例，用...

下述活动图粗略阐释了"获取棋盘信息"用例的内部活动过程.该过程按顺序执行如下操作:1.识别棋串,2.分析棋串,3.制作势力平衡图,3.棋块分析,4.确定棋块的强弱,5.重估势力范围,6.评估打入影响.每个活动内部还有详细的执行步骤,将在用例实现中详细叙述.经过这一系列的操作,棋盘上的棋子分布信息被识别和计算出来,GNU Go的内核基本上象棋手一样,能够"看懂"围棋局势了.参考信息来源:http://www.computergo.net/forum/viewthread.php?tid=724&extra=page%3D1主要参考内容:第4节,信息获取.........

目前已经有四十七位专家和网友加入了我的"跟我学UML业务建模"圈,我已经完成了业务系统的服务体系-业务用例建模的基础知识讲座,现准备进入业务系统的执行体系-业务对象建模基础知识的讲解中,现开始征集问题和反馈...请各位圈友:提出自己感兴趣的问题...,对已经完成的业务用例建模概念还不明白的提出疑问...,对实践应用中遇到的具体建模难题提供案例.推荐感兴趣的朋友加入我们的圈子,当圈子成员发展到50名的时候,我就开始讲解业务建模的主体内容:业务对象模型的基础知识.一个月只增加了10名圈友,按此速度可能要到春节之后开讲了,请各位已经加入的圈友或者耐心等待,或者....12月27日离开讲还差11名圈友,继续等待...2007年3月10日,看来圈友们宣传得不够啊......哈哈!离开讲还差3名圈友,继续等待...2007年4月6日...即将拉开帷幕,敬请关注,多多分享.今天,我们...

在我的职业生涯中，面向对象建模技术一直在给与我帮助。她帮助我从一个刚毕业的学生变成一位面向对象的程序员、设计员，然后成为主持重要软件项目分析师、项目经理和部门经理，接着成为软件公司的技术总监、董事和自动化公司的副总经理。这门技术一直伴随着我，让我的思想方法始终坚实有效，她给了我越来越大的帮助。简单地说，面向对象技术一直在帮助我朝更加成功的方向前进。我想，可能有许多朋友目前正处于我曾经和正在经历的职业生涯阶段，他们都会用得着我的体会的。所以，在接下来的篇幅里，我会假设面对四种不同类型的读者分别交流，提出我认为是关键的一些体会。而且，在接下来的一段时间内，我也会定期到软件协会网站上开辟的相关技术交流讨论组上去，举一些实例来介绍更具体的建模经验，上去回答读者的疑问，对于我来说，我更加希望能有机会回答一些实际项目中遇到的问题，如果问题具有挑战性，我甚至愿意跟踪到读者的项目中去，深入了解读者的问题，...

[讨论]大家帮我分析这个项目下一步该怎么做？ 前段时间中标了某局的网上审批和网上交易系统，这是个全省试点项目。经过一个月的调研分析后，发现该局根本不具备项目实施条件。1、计算机应用水平极差（仅仅因为今年成为试点，所以才采购的计算机设备），上网都很困难；2、为什么要选用该局做试点，因为这个市比较小，省厅认为实施难度会小一些；3、网上审批现有流程是：由审批服务大厅窗口负责业务受理，报材料到业务科室，科室审查后交领导批示，然后再到政府。业务科室要对办理事项负责，这样将直接导致业务科室必须对纸质文件进行审查，同时报给政府的也肯定需要纸质文件，最终的结果是审批系统根本用不起来。4、传统业务流程转移到网上交易后，会触动业务科室及领导的利益，领导并不希望公开。针对这个项目我有两个出路：1、糊弄了事：仍然按各业务科室确认需求进行开发、实施和培训，能不能用的起来是他们的事情；2、帮他们把应用做起来：(1)首...

...业被告知:不上MES这套衣服,鞋帽就搭配不上了.显然，我上面的假设是不符合事实的，大企业可以穿名牌高档的帽衣鞋，小企业同样也要（可以）穿帽衣鞋，只不过可以简单便宜些罢了，大中小企业一定有在本质层次的同类的需求的。那么，MES满足的本质层次的需求是什么呢？探究这个问题，有可能发现一条演进式的，符合我们现实状况的MES，乃至ERP,SCM之...

...把“部门汇总表” 交给各部门经理审核，把“工资结算总表”交给总经理审批。4．    财务部经理跟踪部门经理和总经理的审核和审批结果，在得到肯定没有问题...

这几天机器被病毒搞垮了，没上来，今天上来发现圈子的人已经飙升到17人，大受鼓舞，正好赶上畅享网更新版面。UML系统建模实战讲解正式开始了。我先申明，本实战讲解假设本人带领一个小型团队开发所举实际项目例子，讲解本人认为所必要的文档。不以RUP为参照，其中穿插UML系统模型建模成果片断帮助团队成员理解分析和设计。由于没有真实开发团队配合，模型演进过程可能会由于虚构太多而脱离实际，或前后不一致，请圈友仔细辨识，积极探讨。下面开始正文 一种基于互联网的翻译交易系统 商机： 我们或许经常会遇见类似下面的情形： 1．  有很多人想把自己的产品资料翻译成外文向国外的客户推介，以寻找海外市场； 2．  听说国外优秀的某篇科技论文和某本著作不错，只可惜是外文，我阅读起来太费劲了，只好等什么时候有翻译版出来。 3．  有个在美国举行国际的技术大会可以在线转播，很多著名...

第一个模型图电脑围棋人机对弈程序的核心是着手生成器，用来根据当前局势产生下一手棋下在何处。一个着手生成器包含一个分块器，一个棋块安全性计算器和一个着手效率计算器，也就是说，围棋着手主要依据下一步棋将产生怎样的棋块？其块的安全性如何？着手效率高低几个指标进行评估，找到评估最优的着手作为下一手。以上模型和分析依据是遵照在网上找到的下述资料进行的：附件：“手谈”的编程技术    “手谈”的走棋主要决定于静态评价。直至1994年的早期版本,   走棋选点没有用到搜索法。1995年试把搜索法用于走棋选点,   但棋力未见提高。近年虽有些提高,   搜索法的作用还是不能满意的。最近我做了一个选点不用搜索的“手谈”版本。它在与有选点搜索法的版本对弈时似乎...

虽然本人是电力系统老牌硕士了，但哪些书本知识早就忘得差不多了，但感觉自己的UML运用已算是进阶了，于是想到一个比较大的想法：用UML对整个电力系统的业务进行一个系统的建模。我有电力系统知识基础，常年电力自动化产品研发的经验，但对电力系统中的发电企业，电网公司，供电企业的具体实际业务了解的还不够。这个圈子里应该会有这方面的专家吧？因为这件事比较大，对电力系统信息化的意义也非同寻常，所以对参与人的要求也比较高，轻易不能启动，否则，容易半途而废。有谁愿意来和我一起做这件有意义的事呢？...

电力系统UML业务模型概述 价值链关系 l 定义：电力系统是围绕电能的运作和经营过程中有关资源及其变化过程的总称。电力系统的价值目标是取得在电能运营中如下方面因素之间的最优化平衡： n 较低的消耗和损耗； n 较高的电能供应的安全性和可靠性； n 较高的电能质量； n 适当的电能供应数量和速度。 l 有关对象：电力系统 l 有关过程：电能的运作和经营过程。 l 价值实现过程：电力系统从能源材料供应商处取得能源材料，经过电能的生产、运送和供应过程，最终满足电能用户的电能需求,获得电能用户回报。 电力系统价值链的“业务用例模型”表达...

价值链的实现 电力系统分工 电力系统是经济社会的重要组成部分之一，因此，必须首先遵循经济社会的规则和规律，同时，电力系统还必须遵循电气物理的自然规律进行组织、构建和运行，根据这一特点可将电力系统划分为两个层面的系统： 1． 电力运营系统：完成电能经营活动的整体运作的系统。电能运营系统主要负责电能需求获取、电能需求规划和电能生产计划、采购计划、销售计划的制定和实施，以及相配套的基础设施的建设。 2． 电力生产系统：根据电能运动的自然规律，完成电能的生产、运送和供应等过程的生产执行系统。根据生产过程中的地位和作用不同，生产系统可细分为电源系统，电网系统和负荷系统。 电力运营系统和电力生产系统是同一个系统的不同工作层面。电力运营系统工作层面较电力生产系统的工作层面高。电力运营系统为电力生产系统提供目标和要求，电力生产系统为实现电力运营的目标进行具体的生产活动。电力运营系统保证一段时...

电力运营系统 静态结构关系模型 主要对象 l         电力运营系统：完成电能经营活动的整体运作的系统。 l         电力营销系统：完成对电能需求的获取、电能（或原始能源材料）的采购、电能的销售和电能使用咨询等过程的系统。 l         电力规划设计系统：完成对某区域用户电能需求的历史和趋势分析，发现供需矛盾，寻求合理优化方法，设计实施方案，制定电力基础设施建设和维护计划的系统。 l         电力建设系统：负责组织相关资源，实施电力...

电力生产系统 静态结构关系模型 电力生产系统组成和结构的“类-关联”图表达 主要对象 l         电源系统：负责生产出电力能源的系统，具体包括各种类型的发电厂。 l         电网系统：负责把电力能源从电源所在地运送到负荷所在地的系统。 l         负荷系统：负责消耗电力能源，利用电力能源来推动社会经济的系统，负荷指的是各种需要电力来驱动的设备和电器产品，如机床、电视、空调等。 l         电能：以电...

...uo;类-方法”图表达 该图是对电力生产系统静态结构关系图的一个补充，通过对系统需要进行的动态过程的跟踪叙述，可以发现静态模型中的对象应该具备的对外表现的能力或承担的职责。通过静态模...

电能运送 电力系统的电网系统主要承担电能运送的职责。电能的运送和普通货物的运送形式上有相似之处，也包括电能的接受、汇集、输送、中转、分配、输出等环节，除了电能的接受和输出环节分别和电源系统和负荷系统相关以外，其余环节全部在电网系统内部完成，就象一个专业的物流公司，除了收货和送货与发货人和最终收货人有关外，其余的运输过程则全部是物流公司的内部事务。 描述电能运送的外部交互行为的“事件流图”如下，电网系统从电源系统获得能源后，经过电网内部的、汇集、输送、中转、分配过程，在此过程中电能发生转移，并产生损耗，最后输出给负荷系统。在本篇概述中，对电网内部的运行过程和对象，在这里不继续展开分析，留到后面专门的章节进行详细的分析。 从这个事件流图中，我们也可以分析得到“电网”这个整体对象，在围绕贯通这个事件流的目的上，自身对外必须肩负的整体职责或应具...

电能供用 电能供用的职责是由营销系统、电网系统和负荷系统共同来完成的。作为生产系统的一部分，电网系统和负荷系统主要承担电网的配电设备和用户的受电设备正常运行，电能能够顺利完成消耗的物理过程的职责，其他经济和管理方面的职责，则主要通过电力营销系统来完成。 在电能供用环节中的外部主要交互事件顺序，用事件流图表达如下： 电能经过电网的输电网络从发电侧运送到需求侧，然后经过电网的配电网络传送到用户的受电端，通过受电变压器将高压电能转换成380V低压电能，通过用户的配电系统，才能为用户的各类用电负荷提供电能，用户的配电系统，连接适当的用电负荷并投入运行，消耗所需的电能。 需要指出的是，电能产品是一种特殊的产品，由于电能的传输速率是光速，也就是说，在时间上，电能产品几乎在生产出来的一瞬间就完成了运送、交易和使用消耗的全过程。我们使用了事件流图来表达各类事件的先后顺序，只是为了在逻辑上说明各类事...

电系系统宏观架构模型 本节使用了一个UML部署图来对电力系统的宏观架构的理解，该部署图小结并稍微延伸了上述“价值链实现”中谈到的相关对象，得到了从“最高”的物理视野上来观察电力系统所能看到的主要部件的业务逻辑分布，表达了对电力系统“硬件”架构的总体认识。 部署图的横向表达了业务性质的层次，纵向表达的是业务过程的界限。从图中可以看到：我们本篇前面的叙述中，在电力运营层采用的先是从横向划分的办法，也就是不分业务过程领域，只看业务性质层次，我们分出了规设，电建和营销三个子系统，然后，在此图中我们延伸了纵向的划分，就分出了针对不同业务过程领域，不同业务性质的更细的子系统。比如，电力营销系统就可以更细分为发电厂营销、电网营销和需求侧管理系统，各子系统就成为逐渐精细的业务模型分析中相对独立的单位。   &...

如果你熟悉某个业务领域，希望总结这个业务领域的业务运作的一般性规律，并用清晰的模型表达出来，请加入这个圈子，并提供您的建模需求。如果你是熟悉其他的业务建模方法，在业务建模过程中遇到不好表达的疑难杂症，或者你认为有其他方法可以表达，而UML面向对象方法无法表达的问题，请请加入这个圈子，并提出挑战的建模要求。如果你是建模爱好者，希望学习使用ROSE工具运用UML表达业务模型，并愿意承担做一些"家庭作业"的任务，请加入这个圈子，并提出希望的作业类型。...

...，我们可以折射出企业的一些战略意图。我对软件企业的熟悉范围，也仅局限在软件过程和...

...际上领导对发工资整体时间进度的一个安排...

...要制定更远大的目标，否则，我们将被竞争对手挤出圈。 其实，我们并没有看到更为严重的威胁：在软件行业，我们只是在和国内几个对手在“舞枪弄棒”而已，我们以及我们目前的几个对手的勇气、力量和智慧全花在大刀、梭镖、木棍上，确实，我们武术精湛、武功高强。可是，中国面临WTO，面临国门洞开，我们面临武装了飞机、航母、导弹的洋鬼子，在软件行业，他们已经制定了CMM、掌握了UML、运用了JSP，PHP；手里还抓着大把US$，就象上世纪交接期的一位先人画的那只大鹰，在我们上空盘旋。我们的邻国印度，有2000多家软件企业通过了ISO9000系列认证，５８家通过CMM认证。而我们，还只够使用结构化这种原始战术，连OMT这种小米加步枪的武器都还使不太转。我们通过CMM二级认证的软件企业是凤毛麟角。我们的灭顶之灾就要来临，还想端着梭镖冲出国门，这简直就是悲哀。也许我们中有人还...

UML中文手册精选 用例图、活动图.........