<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>J2EE  Architect----Service Oriented  Architecture - UML/ROSE</title><link>http://blog.csdn.net/smarttony/category/269241.aspx</link><description>UML/ROSE</description><dc:language>zh-CN</dc:language><lastUpdateTime>Mon, 21 Apr 2008 16:47:12 GMT</lastUpdateTime><ttl>60</ttl><item><dc:creator>SmartTony</dc:creator><title>UML 基础: 类图</title><link>http://blog.csdn.net/smarttony/archive/2008/03/07/2157209.aspx</link><pubDate>Fri, 07 Mar 2008 20:19:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2008/03/07/2157209.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2157209.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2008/03/07/2157209.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2157209.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2157209</trackback:ping><description>这是关于统一建模语言、即UML 里采用的基本图的一系列文章的一部分。在我 先前关于序列图的文章 里，我把重点从 UML 1.4 版，转移到 OMG的采用UML 2.0版草案规范（又称为UML 2）。在这篇文章中，我将会讨论结构图，这是已经在 UML 2 中提出的一种新图种类。由于本系列文章的目的是使人们了解记号元素及它们的含意，该文主要关注类图。你很快就会知道这样做的理由。随后的文章将会覆盖结构范畴中包含的其它图。 &lt;img src ="http://blog.csdn.net/smarttony/aggbug/2157209.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>UML 的九种模型图</title><link>http://blog.csdn.net/smarttony/archive/2008/03/07/2157148.aspx</link><pubDate>Fri, 07 Mar 2008 19:50:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2008/03/07/2157148.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2157148.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2008/03/07/2157148.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2157148.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2157148</trackback:ping><description>1. UML的模型图
    UML 的模型图能够将被建模的系统的某一个方面的某一部分以图形的方式表示出来，不同的视图通过将多个不同的模型图有机组合在一起就能够描述系统模型的某方面的特征。UML的模型图是有模型元素构成的，模型元素以图标的形式直观形象的表达各种概念。有的模型元素可以在多个模型图中使用，如注释和注释连接可以在任何模型图中使用，用于给其他的模型元素进行注释。各种模型图能使用的模型元素集合也不相同，在介绍各种模型图的时候会有具体的说明。

    UML 定义了九种模型图：用例图（Use Case View）、类图（Class Diagram）、对象图（Object Diagram）、构件图（Component Diagram）、部署图（Deployment Diagram）、状态图（StateChart Diagram）、活动图（Activity Diagram）、序列图（Sequence Diagram）以及协作图（Collaboration Diagram）。这九种模型图各有侧重，如用例图侧重描述用户需求，类图侧重描述系统具体实现；描述的方面都不相同，如类图描述的&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2157148.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>SOA 建模: 第 4 部分 服务合成</title><link>http://blog.csdn.net/smarttony/archive/2008/02/01/2077538.aspx</link><pubDate>Fri, 01 Feb 2008 22:28:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2008/02/01/2077538.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2077538.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2008/02/01/2077538.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2077538.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2077538</trackback:ping><description>

服务合成

现在，服务已全部由一些提供者提供，我们已经准备好将这些提供者集合起来使用，实现最初的业务需求。这种集合根据业务需求来合成和设计服务，为 Purchasing 服务提供一种方法。我们将创建一个 OrderProcessor 合成要素，为处理定购单提供一个购买服务。这个服务提供者要求服务被 InvoicingService、Scheduling 和 ShippingService 服务规范定义。我们将创建一个 OrderProcessing 合成要素，它集合了 Invoicer、Productions 和 Shipper 合成要素的实例，以及 OrderProcessor 合成要素，从而执行处理定购单的操作。

Order Processor 服务提供者

定购单处理服务由 Purchasing 服务规范指定（请参见图4），该规范包括如下功能（或者操作）：

+ processPurchaseOrder (customerInfor : Customer, purchaseOrder : PurchaseOrder) : Invoice 

&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2077538.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>SOA 建模: 第 1 部分 服务识别</title><link>http://blog.csdn.net/smarttony/archive/2008/02/01/2077516.aspx</link><pubDate>Fri, 01 Feb 2008 22:13:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2008/02/01/2077516.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2077516.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2008/02/01/2077516.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2077516.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2077516</trackback:ping><description>本文是五篇系列文章中的开篇之作，本系列文章是有关基于面向服务的架构（SOA）的软件开发。它介绍了如何使用 IBM® Software Service Profile 扩展的 UML 模型设计同业务需求相连接的 SOA 解决方案，而它至今仍然是独立于解决方案的执行的。作者首先描述了业务目标以及满足这些目标所要执行的业务过程，然后解释了如何使用该过程识别那些完成他们所提需求所必须的业务相关的服务。&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2077516.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>UML基础: 统一建模语言</title><link>http://blog.csdn.net/smarttony/archive/2008/02/01/2077515.aspx</link><pubDate>Fri, 01 Feb 2008 22:11:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2008/02/01/2077515.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2077515.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2008/02/01/2077515.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2077515.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2077515</trackback:ping><description>回顾20世纪晚期--准确地说是1997年，OMG组织（Object Management Group对象管理组织）发布了统一建模语言（Unified Modeling Language，UML）。UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。UML提出了一套IT专业人员期待多年的统一的标准建模符号。通过使用UML，这些人员能够阅读和交流系统架构和设计规划--就像建筑工人多年来所使用的建筑设计图一样。&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2077515.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>uml统一建模语言</title><link>http://blog.csdn.net/smarttony/archive/2008/02/01/2077507.aspx</link><pubDate>Fri, 01 Feb 2008 22:05:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2008/02/01/2077507.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2077507.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2008/02/01/2077507.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2077507.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2077507</trackback:ping><description>面向对象的分析与设计(OOA＆D)方法的发展在80年代末至90年代中出现了一个高潮，UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。  
　  
1. 标准建模语言UML的出现   
公认的面向对象建模语言出现于70年代中期。从1989年到1994年，其数量从不到十种增加到了五十多种。在众多的建模语言中，语言的创造者努力推崇自己的产品，并在实践中不断完善。但是，OO方法的用户并不了解不同建模语言的优缺点及相互之间的差异，因而很难根据应用特点选择合适的建模语言，于是爆发了一场“方法大战”。90年代中，一批新方法出现了，其中最引人注目的是Booch 1993、OOSE和OMT-2等。   
&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2077507.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>作UML图的软件有哪些 </title><link>http://blog.csdn.net/smarttony/archive/2008/01/30/2073341.aspx</link><pubDate>Wed, 30 Jan 2008 15:41:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2008/01/30/2073341.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2073341.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2008/01/30/2073341.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2073341.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2073341</trackback:ping><description>作UML图的软件有哪些:
1.   Rational   Rose(IBM) 
2.   Visio(MS) 
3.   Power   Designer
4.   Visual   Paradigm
5.   together
6.   Magic   draw
&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2073341.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>OO系统分析员之路--用例分析系列（3）--业务建模之涉众</title><link>http://blog.csdn.net/smarttony/archive/2008/01/23/2062069.aspx</link><pubDate>Wed, 23 Jan 2008 21:49:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2008/01/23/2062069.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2062069.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2008/01/23/2062069.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2062069.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2062069</trackback:ping><description>在了解了系统目标以后，系统分析员最先要做的事情不是去了解业务的细节，而是去发现与这个目标相关的人和物。英文把这种人和物称为Stakeholder，在Rose中，这类模型的类型被定义为Business Actor 。有的资料翻译为干系人，笔者则更喜欢涉众这种翻译方法。这就谈到了业务建模的第一步：发现和定义涉众。

&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2062069.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>从六个角度分析流程建模 </title><link>http://blog.csdn.net/smarttony/archive/2008/01/10/2034393.aspx</link><pubDate>Thu, 10 Jan 2008 20:44:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2008/01/10/2034393.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2034393.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2008/01/10/2034393.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2034393.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2034393</trackback:ping><description>从六个角度分析流程建模 流程是由多个要素组成的系统，可以从不同的维度或视角（perspective）描述，通常包括功能、业务逻辑、组织、知识、目标、数据和产品等，它们表达流程的不同本体（ontology）。其中功能视图表示流程的活动或任务（task）组成；业务逻辑与流程执行方式有关，由若干逻辑控制单元组成；组织视图涉及组织结构、执行主体角色定位等内容；而信息视图包括流程的数据（活动的输入、约束控制和输出）及其关系，涉及流程管理的信息或产品实体描述（product entity details）。此外，面向产品的流程模型强调产品（活动结果）在流程中的转换过程，包括状态顺序及转化条件等内容，弱化了功能活动。目标是与流程的功能粒度有关系的，即流程的子目标与流程的分解对应，是考核功能主体绩效的依据，常用的方法是平衡记分法。从不同视角得到的流程模型大多表现为某种流，如信息流、知识流和业务流等。文献1在研究流程的属性时，就是从功能（function）、行为、组织、信息、决策和资源等角度考虑[1]。流程的各种要素之间的关系如图1所示。  

&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2034393.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>业务建模</title><link>http://blog.csdn.net/smarttony/archive/2008/01/10/2034389.aspx</link><pubDate>Thu, 10 Jan 2008 20:41:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2008/01/10/2034389.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2034389.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2008/01/10/2034389.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2034389.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2034389</trackback:ping><description>业务建模是OOAD的重要组成部分，简单的说，业务建模就对业务领域问题进行结构化的描述。这个描述将会直接指导最终生成的软件，业务模型是否具有扩展性，业务模型是否能够正确的反映需求，都将影响最终软件的质量。 

1. 业务建模 

1.1 为什么要业务建模？ 

我们把业务建模这个概念放在了最后的部分，因为面向对象是业务建模的基础。面向对象是一种用计算机语言模拟现实生活的技术。而传统的语言是基于时序的，是计算机观点的语言，和人们熟悉的社会观点是不同的。在软件发展初期时，这并不是什么很大的问题，但是当软件规模越来越大，变化的速度越来越快的时候。人们发现两种观念有了冲突。例如，订单这个对象是人类社会的一个普遍的商业名词，它是相当稳定的。所不同的只是处理规则有所不同，但在传统的语言中，订单的名词并不是关心的重点，关心的重点反而放在了订单的处理时序上。偏偏这部分的处理是不稳定的，所以就引发了变化的问题。而面向对象采用现实世界系统的思考方式，侧重于建立订单这个类型，并构造订单类型的体系，然后再建立规则。所以，他和现实世界的变化频度是基本一致，变化起来也就比较容易。 
&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2034389.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>策略→需求→建模→规划→执行</title><link>http://blog.csdn.net/smarttony/archive/2008/01/10/2034382.aspx</link><pubDate>Thu, 10 Jan 2008 20:34:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2008/01/10/2034382.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2034382.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2008/01/10/2034382.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2034382.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2034382</trackback:ping><description>策略 需求 建模 规划 执行 当二十一世纪进入知识经济时代后，企业所面临的挑战也越来越严格。而善用信息技术于经营策略，绝对是企业赢的关键因素之一。企业信息化所需的 IT 技术越来越多、越来越复杂，而更重要的是 A 公司必要的 IT 需求，却不见得 B 公司也需要。因此，在这种趋势演变下，事先规划与确认符合企业经营策略的 IT 需求，是新一代的企业信息部门所必须负责的关键任务之一。 

图一所示，以建模为导向的企业 IT 建设参考流程相关步骤解释如下： 

&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2034382.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>关于POJO</title><link>http://blog.csdn.net/smarttony/archive/2007/12/29/2000790.aspx</link><pubDate>Sat, 29 Dec 2007 00:34:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2007/12/29/2000790.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2000790.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2007/12/29/2000790.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2000790.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2000790</trackback:ping><description>POJO 在Hibernate 语义中理解为数据库表所对应的Domain Object。这里的POJO
就是所谓的“Plain Ordinary Java Object”，字面上来讲就是无格式普通Java 对象，简
单的可以理解为一个不包含逻辑代码的值对象（Value Object 简称VO）。

请教一下这里说的POJO和PO是一个概念么?它和VO又是什么关系呢?
一个典型的POJO：
public class TUser implements Serializable {
private String name;
public User(String name) {
this.name = name;
}
/** default constructor */
public User() {
}
public String getName() {
return this.name;
}
public void setName(String name) {
this.name = name;
}
}
关于上面这个典型的POJO有问题需要咨询一下&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2000790.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>第七章 类图</title><link>http://blog.csdn.net/smarttony/archive/2007/12/29/2000775.aspx</link><pubDate>Sat, 29 Dec 2007 00:25:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2007/12/29/2000775.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2000775.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2007/12/29/2000775.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2000775.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2000775</trackback:ping><description>  
前言
    类图是在面向对象的系统模型中使用得最普遍的图。类图包含了一组类、接口和协作以及他们之间的关系。

    你使用类图来为系统的静态视图建模。通常这包括模型化系统的词汇（从系统的词汇表中发现类），模型化协作，或则模型化模式。类图还是一些相关的图的基础，包括组件图、分布图。
&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2000775.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>HOW TO DRAW UML DIAGRAMS</title><link>http://blog.csdn.net/smarttony/archive/2007/12/29/2000768.aspx</link><pubDate>Sat, 29 Dec 2007 00:18:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2007/12/29/2000768.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2000768.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2007/12/29/2000768.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2000768.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2000768</trackback:ping><description>HOW TO DRAW UML DIAGRAMS



What is UML?
UML stands for Unified Modeling Language. This object-oriented system of notation has evolved from the work of Grady Booch, James Rumbaugh, Ivar Jacobson, and the Rational Software Corporation. These renowned computer scientists fused their respective technologies into a single, standardized model. Today, UML is accepted by the Object Management Group (OMG) as the standard for modeling object oriented programs.



&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2000768.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>SmartTony</dc:creator><title>用UML建模需要注意的问题</title><link>http://blog.csdn.net/smarttony/archive/2007/12/29/2000765.aspx</link><pubDate>Sat, 29 Dec 2007 00:16:00 GMT</pubDate><guid>http://blog.csdn.net/smarttony/archive/2007/12/29/2000765.aspx</guid><wfw:comment>http://blog.csdn.net/smarttony/comments/2000765.aspx</wfw:comment><comments>http://blog.csdn.net/smarttony/archive/2007/12/29/2000765.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/smarttony/comments/commentRss/2000765.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=2000765</trackback:ping><description>用UML建模需要注意的问题
用UML建模时，对软件开发过程是有要求的，必须是用例驱动，以架构为中心，迭代和递增的开发，如果软件开发组织的软件开发过程不能满足这三点要求，那么UML的使用效果就会大打折扣，下面详细论述：
一、 用例驱动
用例驱动意味着为系统定义的用例是整个开发过程的基础。
用例在多个核心工作流程中都发挥了作用。 
&lt;img src ="http://blog.csdn.net/smarttony/aggbug/2000765.aspx" width = "1" height = "1" /&gt;</description></item></channel></rss>