标签：UML

转自：umlchina yahoo讨论组

　　To: UMLChina@yahoogroups.com

From: "赵鹏" <zhaopeng@webservice.com.cn>  Add to Address Book  Add Mobile Alert 

Date: Fri, 13 Jan 2006 12:49:01 +0800

Subject: 答复: 回复： [UMLChina] 开发一个dvd play er系统，用例到底应该如何划分呢

   

一般而言，一个用例就是参与者的一个目标，它是一个可观察到、可度量的过程。

对于参与者是一个在有限时间内可完成的一个过程。

如“播放碟片”，从不同角度看，就会有不同的解释。

从功能看，就是播放机上的一个按钮，是播放机的一个功能。

从目标看，对参与者是一个完整的过程，它包含一些列的功能(其中包括上面的功能)，它是参与者的一个意图。

如果把“播放碟片”写成用例可能像如下的例子

 

播放碟片(仅作示例)

参与者：想看碟子的人

前置条件：播放机已经接通电源。

主要场景：

1、参与者打开播放机电源。

2、播放机点亮电源指示灯。

3、参与者打开碟片舱门。

4、播放机弹出舱门，指示灯闪烁。

5、参与者关闭舱门。

6、播放机确认舱门正确关闭，并确认碟片可以播放，显示碟片时间。

7、参与者播放碟片。

8、播放机按照碟片预设的流程播放。

扩展

3a、如果参与者连续发出关闭和打开舱门命令，播放机近当舱门打开后才接受最后一条指令。

3b、如果参与者发出其它指令，播放机将忽略。

5a、如果参与者连续发出关闭和打开舱门命令，播放机近当舱门关闭后才接受最后一条指令。

5b、如果参与者发出其它指令，播放机将忽略。

6a、碟片不可识别，播放机弹出碟片。

8a、参与者可以随时中止播放。

 

相关的用例可能还会包括：

一、用户从指定时间处开始播放。

二、用户回看播过的内容。

。。。。。。。

 

从上面的用例可以看到“播放碟片”即出现在用例这个层次，也出现在具体功能这个层次（本人觉得应该避免这种名次的混淆，此处仅作为示例）。

从指这样的用例可以分析和提炼出，一个播放机具体需要具有哪些系统特性，即可以得到一个功能列表，如你在问题中所提到的。

系统特性，可以用“系统可以做....”这样的语句来验证。

如，播放机可以播放碟片、播放机可以调到指定时间、播放机可以快进.............

 

 

--------------------------------------------------------------------------------

赵鹏

软件开发部

上海星移软件有限公司

MSN:dearzp@hotmail.com

Email:zhaopeng@webservice.com.cn

Biz Tel:021-54395480

more for www.webservice.com.cn

 

--------------------------------------------------------------------------------

发件人: UMLChina@yahoogroups.com [mailto:UMLChina@yahoogroups.com] 代表 周

发送时间: 2006年1月13日 12:15

收件人: UMLChina@yahoogroups.com

主题: 回复： [UMLChina] 开发一个dvd player系统，用例到底应该如何划分呢

 

如果说快进快退实现了用户定位影片的目的，可以作为单独的用例，那类似于“下一曲”“上一曲”以及搜索查找都可以做为单独的用例吗？

weijie xu <iam_xuwj@yahoo.com.cn> 写道： 用例的粒度大小是否合适，主要还是要看这个用例是否已经实现了对用户有价值的结果，或者实现了用户的某一个有价值的目标。对于"停止播放"来说，用户的真正目的并不是仅仅用DVD播放软件来停止播放DVD，停止播放单独存在对用户而言毫无意义，只能是作为播放DVD过程中的一个步骤。所以“停止播放”不能作为一个单独的用例，只能作为“播放DVD”这个用例中的一个步骤，并且是最后一步。“快进快退”则不同，它的存在对用户而言是有意义的，它实现了用户定位影片的目的，可以作为一个单独的用例存在。而“选时播放”则是一个比较特殊的播放用例，可以将“播放DVD”include进来，以实现重用和简化的目的。

 

一家之言，仅供参考。

iadomcn <iadomcn@yahoo.com.cn> 写道：

对于用例粒度的选择有点疑惑，

用户作为主要的参与者，以＂播放DVD＂作为用例，

如果仅仅只是这个用例似乎又包含太多的东西，如＂停止播放＂，＂快进快退＂＂

选时播放＂等等，还是这些都可以单独作为用例呢

那样是不是又将用例划分的太小呢，用例之间的　关系将变得复杂起来

请教　到底应该怎样来划分用例呢

转自：http://www.uml.org.cn/UMLApplication/200509273.htm

 UML软件工程组织 　　　　北京火龙果软件工程技术中心

 

--------------------------------------------------------------------------------

《UML:Java程序员指南》的读书笔记

来自：http://blog.csdn.net

1.  第一章 针对Java程序员的UML概述

    1.  UML(统一建模语言)的三个层次：

        1.  概念层(Conceptual)

            接近人类自然语言

            有歧义

            无严格的格式

          

        2.  规格说明层(Specification) 

        3.  实现层(Implementation)   

             规格说明层和实现层接近代码、无歧义、有严格的格式

                                           

    2.  UML分三类：

        1.  静态图（static diagrams）

            描绘类、对象、数据结构以及存在于它们之间的逻辑关系。

      

        2.  动态图（dynamic diagrams）

            描绘运行期间，软件执行流程和软件实体状态改变的方式。

      

        3.  物理图（physical diagrams）

            描绘物理实体，如：源文件、库文件、字节文件、数据文件等，以及它们之间存在的逻辑关系。

          

    3.  类图（静态图）

        1.  长方形表示类，箭头表示关系。

        2.  图中的所有关系叫关联（associatons），关联的命名对应引用的对象的变量名称。

      

    4.  对象图（动态图）

        可以看成是内存的一个快照，主要反应程序中的对象在运行期的信息。

        1.  对象名称有下划线。冒号后面跟着对象类型的名称。

      

        2.  对象之间的关系叫链接（links），链接的命名同样对应引用的对象的变量名称。

      

    5.  序列图（动态图）

        几个术语：

        1.  监护（guards）

      

        2.  构造（construction）

      

        3.  数据标记（data token）

      

        4.  活动（activation）

      

    6.  协作图（动态图）

        序列数的点结构

      

    7.  协作图和序列图的异同点

        同：它们包含的信息相同

        异：协作图描述对象之间的关系，序列图描述消息被执行的前后顺序。

      

    8.  状态图（动态图）

        限定状态机（finate state machines）

        图中的箭头被称为转换（transitions）

  

2.  第二章 使用图

    1.  为何要制作模型？

        制作模型的目的是为了证明模型是否可以正常工作。

        一个模型必须有一个可用的检验标准。

      

    2.  使用UML的时机：

        1.  需要通过检验来确定某些东西是否可用的时候。

        2.  使用UML来检验比用编码来检验更划算的时候。

      

    3.  有效的使用UML

        1.  使用UML在开发人员之间传达设计概念。

            使用UML创建具体算法对应的图，并不方便。

            UML对创建大型软件结构的“路线图”，比较有用。

            通过UML图可以清楚的发现类与类之间的依赖关系和整个系统的结构。

          

        2.  保留和舍弃

            大多数的UML图都是短命的，应该舍弃的。只需记录在白板或白纸上。

            但下列图应该保存下来：

            1.  表现系统中一个通用设计的解决方案的UML图。

            2.  记录了复杂的协议，难以通过代码了解的UML图。

            3.  提供了较少涉及到系统范围内的“路线图”的UML图。

            4.  比代码更易表述设计意图的UML图。

          

            这些保存下来的UML图，应该经过多次迭代精化修改，最终版本应保存在团队都能访问的公共区域。

            长期保存与临时创建的UML图应该分开存放。

      

        3.  迭代精化

            先研究动态场景，然后确定静态结构的内在含义。

            对动态图（如：协作图）和静态图（如：类图）进行多次迭代并不断完善。

          

      

    4.  最适合创建文档的时机：

        团队完成了所有工作，项目即将结束的时候。

      

    5.  使用Interface实现事件机制，避免了button对Dialler的依赖。

        这样按下按键之后可以拨号，也可以做别的事。

      

    6.  适配器

        适配器也叫转接器，用于在一件或多件仪器的不同部件之间实现有效兼容性的装置。

        适配器的作用：实现接口，转发消息。

      

    7.  画UML图时应时刻想像着如何转化为代码。

  

    8.  UML图的目标并不是要如何正确，而是要讨论它的人都理解它，所以UML图应尽量简洁。

      

    9.  什么时候画UML图：

        1.  多人参与开发，且这些人需要理解一个系统的特定部分的设计结构时，开始画UML图。

            所有人都声明已经理解了的时候，停止画UML图。

          

        2.  两个或多人之间对某个设计点产生意见分歧，进行讨论时，需要画UML图。

            讨论完毕，做出决定后，停止画UML图。

          

        3.  思考一个设计时，画UML图会有所帮助。

            思考成熟并完成相应的代码后，停止画UML图。

          

        4.  向他人或自己解释一段代码的逻辑结构时，开始画UML图。

            发觉看代码能理解的更清楚时，停止画UML图。

          

        5.  当项目快要结束，客户需要UML图和文档时，开始画UML图。

      

    10. 什么时候停止画UML图：

        1.  画图并不是一个必经的过程。

        2.  好的设计者只有在需要的时候才编码和画UML图。

        3.  不要在编码之前的设计阶段，去为创建全面的文档而画UML图，这是浪费时间。

        4.  不要为了其他人编码而去画图。

      

    11. UML Case工具：

        1.  UML Case 工具的弊：

            1.  正版价格贵

          

            2.  需要学习周期

      

        2.  自动绘制UML图的协作系统，应当在手动协作系统不够用的时候才去考虑它。

      

        3.  项目中使用UML Case工具或集成于IDE的UML Case工具，应先进行效能实验，三思而后行。

      

    12. 文档

        必须建立文档，但必须谨慎地创建文档。

        软件文档应该言简意赅

        一个软件文档的价值通常与文档的大小成反比。

        wiki是一个团队中协作编写文档的不错方法。

      

3.  第三章 类图

    1.  类图描绘类本身的信息，以及类之间的关系。

  

    2.  类使用正方形表示

        "-"表示私有（private），"+"表示公有（public），"#"表示受保护（protected）

        Figure UML-5-2-1

       

        Figure UML-5-2-1 对应的代码

        public class Dialler

        {

            private Vector digits;

            int nDigits;

            public void digit(int n);

            protected boolean recordDigit(int n);

        };

      

    3.  关联

        大多数情况下是表示对象实例持有着对其它对象的引用。

        Figure UML-5-3-1

       

        Figure UML-5-3-1 对应的代码

        public class Phone

        {

            private Button itsButtons[15];

        };

      

    4.  多重性

        Figure UML-5-4-1

       

        Figure UML-5-4-1 对应的代码

        public class Phonebook

        {

            private Vector itsPnos;

        };

      

        "*"表示数量非常多，所以PhoneBook的成员变量itsPnos的类型往往使用Vector、List或其它容器。

      

    5.  继承

        约定：为了便于区分，通常用垂直方向的箭头表示继承关系，用水平方向的箭头表示关联。

        在UML中，继承箭头指在基类上。

        Figure UML-5-5-1

       

      

        Figure UML-5-5-1 对应的代码

        public class Employee

        {

            ...

        };

      

        public class SalariedEmployee extends Employee

        {

            ...

        };

      

        虚线继承箭头表示实现一个接口。

        虚线继承箭头指向被实现的接口。

        白板上画虚线耗时，可以马虎一下用实线代替。

        Figure UML-5-5-2

       

        Figure UML-5-5-2 对应的代码

        interface ButtonListener

        {

            ...

        };

  

        public class ButtonDiallerAdapter implements ButtonListener

        {

            ...

        };

      

      

        另外一种表示实现接口的方法：

        Figure UML-5-5-3

       

    6.  在一个UML图中，同时展现所有的方法会引起混乱，所以，只提供一批有代表性的方法会使UML图更清晰。

  

    7.  细节

        细节和修饰符大多数时候并不需要，但是有时候它们是很有用的。

        1.  类的构造型

            类的构造型显示在一对双角括号之间，放在类的名称上访。

          

            Java有两种标准的构造型：

            1.  interface

                interface的所有成员函数都是抽象的

          

            2.  utility（工具类）

                utility的所有成员变量和成员函数都是静态的。

              

            类的构造型可以自己定义，但必须所有阅读UML图的人都明白其含义。

          

        2.  抽象类、抽象方法

            用斜体字或用{abstract}属性，表示一个抽象类或一个抽象方法。

            Figure UML-5-7-2-1

           

            Figure UML-5-7-2-1 对应的代码

            public abstract class Shape

            {

                private  Point itsAnchorPoint;

                public abstract void draw();

            };

          

        3.  属性

            1.  属性不是类的一部分，但可用来代表额外的信息。

                属性可被自定义。

          

            2.  属性的形式：用逗号分隔，由名称、值对组成的列表。

                如：{author=Matin,date=20020429,file=shape.java,private}

          

            3.  一个属性的默认值是true，所以{abstract}等价于{abstract=true}

          

            4.  属性被写在类名称的下方。

          

            5.  一个非正式的约定：在白板上{abstract}可以简写成{A}

          

            6.  一般只使用{abstract}属性。

              

        4.  聚合（Aggregation）

            聚合是关联的一种特殊形式，表示一种整体/部分（whole/part）的关系。

            为了防止混淆，应避免使用聚合

            Figure UML-5-7-4-1

           

            Figure UML-5-7-4-1 对应的代码

            public class Whole

            {

                private Part itsPart;

            };

          

        5.  组合（Composition）

            组合是一种特殊的聚合形式

            组合用的极少

            涉及到一个深度复制的问题。

            Figure UML-5-7-5-1

           

            Figure UML-5-7-5-1 对应的代码

            public class Owner

            {

                private Ward itsWard;

            };

          

        6.  多重性（multipicity）

            对象能够持有其它对象的数组或向量，或者说它们能够持有许多同一类型但不同实例的对象。

          

            多重性的表达式：

            数字        精确的数量，使用数组作为容器。

            *或0..*     0个或0个到无数个，使用Vector作为容器

            0..1        0个或1个，在Java中通常用一个空的引用来实现。

            1..*        1个到无数个，使用Vector作为容器

            3..5        3个到5个，使用数组作容器

            0,2..5,9..* 非法的表达式

          

            Figure UML-5-7-6-1

           

            Figure UML-5-7-6-1 对应的代码

            public class BinaryTreeNode

            {

                private BinaryTreeNode leftNode;

                private BinaryTreeNode rightNode;

            };

          

        7.  关联的构造型

            1.  < >     标准UML标记

                源对象创建了目标对象，然后将目标对象传递给系统的其它对象。

                这种关联可应用于工厂模式。

                Figure UML-5-7-7-1

               

                Figure UML-5-7-7-1 对应的代码

                public class A

                {

                    public B makeB()

                    {

                        return new B();

                    }

                };

              

            2.  < >       标准UML标记

                源对象的成员函数中创建了一个目标对象的实例，把这个实例当做一个本地变量。

                Figure UML-5-7-7-2 同 Figure UML-5-7-7-1 ，图中关联的构造型改为< >

               

                Figure UML-5-7-7-2 对应的代码

                public class A

                {

                    public void f()

                    {

                        B b=new B();

                        //use b

                    }

                };

              

            3.  < >   标准UML标记

                源对象的成员函数把目标对象的实例作为参数使用，源对象不保存目标对象的实例。

                Figure UML-5-7-7-3 同 Figure UML-5-7-7-1 ，图中关联的构造型改为< >

               

                Figure UML-5-7-7-3 对应的代码

                public class A

                {

                    public void f(B b)

                    {

                        //use b

                    } 

                };

          

            4.  < >   非标准UML标记

                源对象传递目标对象的一个成员函数时，用到< >

                < >可应用于多种涉及模式，如：Proxy、DECORATOR和COMPOSITE7。

                Figure UML-5-7-7-4  同 Figure UML-5-7-7-1 ，图中关联的构造型改为< >

              

                Figure UML-5-7-7-4 对应的代码

                public class A

                {

                    private B itsB;

                    public void f()

                    {

                        itsB.f();

                    }

                };

              

        8.  内部类

            Figure UML-5-7-8-1

           

            Figure UML-5-7-8-1 对应的代码

            public class A{

                private class B{

                    ...

                }

            };

          

        9.  匿名内部类

            UML还未对匿名内部类提供官方支持

            一种非官方的表示方法，用有一个< >构造型的嵌入类来表示。

          

            Figure UML-5-7-9-1

           

            Figure UML-5-7-9-1 对应的代码

            public class Window

            {

                public void f()

                {

                    ActionListener l = new ActionListener()

                    {

                        //implementation

                    };

                }

            };

          

          

        10. 关联类

            关联类能进一步的展示一个特殊的关联如何被实现。

            比如：对于多重性关联使用何种容器

          

            Figure UML-5-7-10-1

           

            Figure UML-5-7-10-1 对应的代码

            public class Address

            {

                private Vector itsLines;

            };

          

            关联类能够指明的特定形式的引用有

            1.  不固定的引用（WeakReference ）

            2.  松散的引用（SoftReference）

            3.  幻影的引用（PhantomReference）

          

            Java 2 引用类使用指南-学习如何有效地使用 SoftReference、WeakReference 和 PhantomReference

            http://www-900.ibm.com/developerWorks/cn/java/j-refs/index.shtml

          

          

        11. 关联限定符

            源对象通过某种类型的关键字或标记与目标对象实例发生对应关联时，使用关联限定符。

            Figure UML-5-7-11-1

           

            Figure UML-5-7-11-1 对应的代码

            public class LoginServlet

            {

                private String empid;

                public String getName()

                {

                    Employee e = DB.getName(empid);

                    return e.getName();

                }

            };

          

            关联限定符使用较少

          

        12. 少用UML远比多用UML好。

4.  第四章  序列图（sequence diagram）  动态图  P43

    1.  要点：

        1.  不要为每个类，每个方法建立序列图，这样太浪费时间。

      

        2.  序列图应当用于表现对象间的连接而不是具体的算法细节。

      

        3.  序列图不应有大量的对象和消息返回，而应该抓住本质。

      

        4.  尽量不要用序列图去描述每一个小细节。

      

        5.  代码能足够清晰的说明自己时，图是多余的，浪费的。

      

        6.  应该努力是更多的代码能清楚的描述自己，更少的使用图。（即增强代码的可读性）

      

        7.  小序列图比大序列图容易理解，所以更具有实用价值。

      

        8.  高层图比低层图更有用，因为共性比差异多。

      

        9.  白板上的序列图，用于与同事进行表达、交流。

            文档中的序列图，用于捕获核心的突出的系统协作。

  

    2.  相关术语：

        对象、生命线（life lines）、消息、数据标记（data tokens）、时间（time）、活动（Activation）

      

    3.  生命线

        1.  垂立在对象、类或参与者下面的虚线，与时间同方向。代表对象或参与者的生命周期。

      

        2.  区别对象和类的方法：

            矩形框中对象名下方有横线，类名下方没有横线。

          

        3.  参与协作的对象或类被放置在序列图的顶部横向排开。

      

    4.  人样图

        1.  表示匿名参与者，一般作为消息发起的起点和终点。

      

        2.  并非所有的序列图都有人样图，但大部分都有。

      

    5.  消息

        1.  代表一个对象调用另一个对象（或类）的成员函数。

      

        2.  生命线之间的横向箭头，箭头上方是消息名。

      

        3.  消息的参数使用放在箭头下方的数据标记（data tokens）表示，或者放在消息名后面的括号里。

      

    6.  活动（Activation）

        1.  可选，大多数情况下不使用

      

        2.  沿着生命线的竖向长条形小框

  

    7.  返回值

        表示返回值的横向向左的箭头无须标记名字。

      

    8.  表示创建一个对象的方法：

        一个没有标记名字的消息指向一个被创建的对象上。

      

    9.  表示回收一个对象的方法：

        一个对象的生命线终止在一个“X”上。

      

        消息箭头指向这个“X”，表明一个对象被GC回收。

      

    10. 表示“循环”的方法：

        P49 Figure 4-8

        循环表达式的前缀：

        *[while id:=idList.next()]

  

    11. 表示“分支”的方法：

        P49 Figure 4-8

          

    12. 费时间的消息

        1.  不费时间的消息，完全水平的箭头。

      

        2.  费时间的消息，与水平有个夹角的箭头。

      

    13. 异步消息

        1.  同步消息，使用实心箭头表示。

      

        2.  异步消息，使用空心箭头表示，将消息发送后可立即获回控制权。

      

        3.  序列图可以发现异步系统中的竞争条件（Race condition）。

  

    14. 表示“多线程”的方法：

        P54 Figure 4-12

        消息名称前加上线程标记前缀，来显示几个不同的线程控制。

      

    15. 表示“活动对象（active objects）”的方法：

        活动对象使用粗体框来表示

      

    16. 表示“向接口发送消息”的方法：

        1.  给接口命名对象，然后就像使用一般对象一样来使用。

            这里强调对象符合接口，而不是接口的实例化。

            P55 Figure 4-15

          

        2.  虽然明确知道对象的类类型，但仍要表示消息是被发送到一个接口上。

            P55 Figure 4-16

      

5.  第五章 用例图 （Use Case） 静态图 P57

    1.  概念：

        1.  用例是有关动作性（行为性）需求的文本性描述。

      

        2.  一个用例是有关一个系统的行为的一个描述。

            这个描述是从一个用户的角度编写的。

      

        3.  一个用例捕获一个事件的可视化序列。

            这个事件是一个系统对单个用户的激励（stimulus）的响应过程。

          

        4.  用例不描述系统隐藏着的机制，它只描述那些用户可见的事情。

      

  

    2.  要点：

        1.  诀窍是保持用例的简单。

  

        2.  对于不断发生变化的事情，就不需要过早的去捕获细节。

  

        3.  用例是编写出来的，而不是画出来的。

      

        4.  过早地用用例去记录明天就会发生变化的细节并不值得。

            除非这些用例在近几周内会被实现。

            可以先将这些用例的名称记下来列成表格，维护着。当它们快被实现时，再填充细节。

          

        5.  所有的UML图中，用例图最容易混淆，也是最没用的。但系统边界图除外。

          

    3.  Alistair Cockburn的《有效编写用例》

        书中可了解参与者，次要参与者，前置条件，后置条件等用例的其它要素。

      

    4.  系统边界图

        1.  用途：

            对开发人员提供的信息太少，但可作为向客户讲解的材料。

          

        2.  要素：

            1.  长方形表示系统边界。

          

            2.  长方形里面的任何东西都是需要开发的系统的一部分。

          

            3.  长方形外面是与系统交互的参与者（actors）。

          

            4.  参与者是为系统提供激励的系统外实体。

          

            5.  参与者通常是人类用户，也可以是其它系统，甚至是设备，如实时时钟。

          

            6.  长方形里面的用例（带名称的椭圆形）与刺激它的参与者连接，连线上不带箭头。

          

            7.  尽量忽略用例关系，因为用例关系会引起“扩展”还是“泛化”的争论。

          

6.  第六章 面向对象设计（OOD）原则 P61

    1.  学习下面五个设计原则的目的

        用来评估一组UML图或一批代码是否被适当地设计。

  

    2.  适当设计的系统：

        容易被理解、容易被改变、容易被重用。

        表现为没有特别的开发困难，是简单的、扼要的和经济的。

      

    3.  糟糕设计的臭味的不同成分：

        1.  僵化性（Rigidity）

            难以修改。对一个改动，要修改好几处地方。

          

        2.  脆弱性（Fragility）

            对某个部分的修改，会使不相干的部分出问题。

          

        3.  牢固性（immobility）

            很难拆分成能重用的组件。

      

        4.  粘滞性（Viscosity）

            模块之间结合太紧密，编辑、编译和测试都变得很麻烦。

      

        5.  不必要的复杂性（Needless Complexity）

          

      

        6.  不必要的重复（Needless Repetition）

            存在大量的复制粘贴，代码看起来都很相似。

      

        7.  晦涩性（Opacity）

            代码无法清楚的描述自己。

  

    4.  依存关系混乱的代码就像意大利式细面条般

  

    5.  五种设计原则

        1.  单一职责原则（SRP）

            Single Responsibility Principle

            P62

          

            1.  一个类应当只有一个改变的原因

          

            2.  一个类要处理的事情太多，就会散发出脆弱性的臭味。

          

            3.  书中的例子是一个既要计算薪水，又要读写磁盘，还要打印报表的类Employee。

      

        2.  开放－封闭原则（OCP）

            Open－Close Principle

            P64

          

            1.  应当能够改变一个类的周边环境，而无须改变类本身。

          

            2.  经常违反OCP原则的是GUI

                违反OCP的实现，将所有的行为放入一个使用GUI API的类中。

                遵循OCP的系统，将GUI的操纵与数据的操作分离。

              

            3.  书中的举例是一个数据与操作分离的GUI实现

                P65 Figure 6-6

              

            4.  单元测试的self shunt模式

                http://www.objectmentor.com/resources/articles/SelfShunPtrn.pdf

              

            5.  设计遵循OCP原则，就可以改变dialog和model的周边环境到一个测试环境，而无须对dialog和model作任何修改。

          

            6.  使用抽象（指接口和抽象类）是遵循OCP原则的一个关键。

          

            7.  遵循OCP原则的方法：

                通常是在编写实际代码之前，编写简单的单元测试。这个单元测试使用Test-First（测试优先）方法进行编写。

          

        3.  Liskov替换原则（LSP）

            Liskov Substitution Principle

            P77

      

            1.  避免造成派生类的方法非法或退化，一个基类的使用者应当不需要知道这个派生类。

          

            2.  基类的使用者，为了使用它们的派生类，应当无须做特别的处理。

                这里的特别处理指的是使用instanceof或向下转型（DownCast）操作。

              

            3.  违反LSP原则的两种情况：

                1.  当调用一个派生类的成员函数时发生了非法使用，导致不得不抛出异常。

              

                2.  使用一个退化的派生类的方法，退化是指这个方法什么都不实现。

              

            4.  违反LSP问题的解决方法是：

                为派生类另外寻找一个基类，而不是勉强从现有的基类派生。

              

            5.  书中的举例是把志愿者类作为类Employee的派生类所产生的麻烦。

          

        4.  依存关系倒置原则（DIP）

            Dependency Invertion Principle

            P79

          

            1.  用依赖接口和抽象类来替代依赖容易变化的具体类。

          

            2.  遵循DIP原则可以减少变化对系统的影响，减少系统的敏感度。

          

            3.  从抽象类和接口派生出来的具体类比抽象类和接口的改变频繁得多，

                所以宁可依赖抽象（指接口和抽象类），也不要依赖那些容易变化的具体类。

              

                如果要继承一个类，就从一个抽象类继承。

                如果要持有一个类的引用，就从一个抽象的类引用。

                如果要调用一个函数，就从一个抽象函数调用。

              

            4.  容易变化的具体类是：

                1.  那些正在开发的具体的类。

              

                2.  那些容易变化的捕获商业逻辑的类。

              

                3.  Vector类或String类不算容易变化的具体类。

              

            5.  遵循DIP原则的方法：

                为那些容易变化的具体类创建并依赖于接口。

              

      

        5.  接口隔离原则（ISP）

            Interface Separate Principle

            P79

          

            1.  给一个对象的每一个使用者一个接口，这个接口仅有使用者需要的方法。

          

            2.  肥类（Fat Class）

                一个有着成堆方法的类。

              

            3.  肥类引起的麻烦：

                肥类的使用者不使用类的大部分方法，却会因为这些方法的改变而受影响。

              

            4.  遵循ISP原则的方法：

                为肥类的使用者提供一个只包含它们需要的方法的接口。

              

        6.  设计原则的应用方法：

            1.  试图让系统时时刻刻遵循所有的原则是不明智的。  

      

            2.  应用这些原则的最好方法是反应式（reactively）方法:

                当第一次觉察到代码里有一个结构性的问题存在时，

                或当第一次意识到一个模块的改变被其它模块影响时，

                尝试应用这些原则去解决问题。

7.  第七章 dX实践 P83

    1.  何为dX实践？

        1.  dX实践是一套规则，轻量级的开发过程。

        2.  dX实践其实就是XP（极限编程）实践，XP倒过来就是dX。

        3.  dX实践是短周期迭代式处理所有事情。

            所有事情包括需求分析、设计实现、测试和文档。

            短周期（即迭代周期）就是两个星期。

    2.  初始探索

        1.  第一次迭代探索的是需求，一般不需要花费两周的时间。

        2.  客户是负责需求和负责决策的人。

        3.  与客户讨论的内容：

            1.  系统怎样运作，一些必须的功能。

                不用作详细记录，目标是搞清楚系统的整体状况。

            2.  识别出用例（Use Case）

                把用例名记录在索引卡片上，卡片就是User Story。

                卡片上还可记些其它重要信息。

    3.  功能特征评估：

        1.  对User Story评估，计算系数。

        2.  评估方法：

            1.  以一个已知Story的评估结果作为基础，根据新的User Story的难易程度进行评估。

            2.  用“完美编程”的天数作为标准。

                “完美编程”就是不受任何干扰，在极其理想的环境下编程。

        3.  评估之后要对User Story进行合并和拆分。

            一个User Story的天数应控制在1天到4天之间。

            避免高估自己实力，或评估太保守。

        4.  花两到三天的时间，很快地粗糙地实现两、三个比较有趣的User Story。

            目的是验证评估，获得点数和人天的对应关系。

            这里的人天是粗糙实现得到的。保质保量的实现，一般是粗糙实现的3倍。

    4.  探索

        1.  计算初始速度

            初始速度 ＝ （3 乘以 粗糙实现的人天）除以 被粗糙实现的Use Story的总点数。

    5.  计划

        以计算得到的速度作为标准，计算每次迭代周期中需完成的Story。

    6.  发布计划

        1.  典型的一次发布周期，包括六次迭代周期即三个月

            如果团队有五人，一次迭代周期是两周（十个工作日），

            那么一次迭代周期为50人天，一次发布周期为300人天。

        2.  一次发布周期可完成的点数＝300人天 × 速度。

        3.  客户挑出点数总数为（300人天×速度）的最重要、最有效的User Story，作为发布计划。

    7.  迭代计划

        1.  一次迭代周期为50人天。

        2.  一次迭代周期可完成的点数＝50人天×速度。

        3.  把User Story再细分成任务。

            这里的任务是单个开发人员能够负责的简单任务，以4到10人小时为单位。

            这个细分过程需要客户协助识别重要和次要的用户接口。

        4.  细分结束，开发人员挑选符合自己预算的任务。

            对于剩余任务要进行分摊。

            最后的未决任务要和客户商量是否挪到下一个迭代周期。

            直至所有的任务都分配出去。

    8.  中点

        根据前半段迭代周期中完成任务的点数，对后半段剩下的任务进行调整，取消或增加任务。

    9.  速度反馈

        1.  迭代周期结束的时间不能变更。

        2.  根据实际完成的点数重新计算速度，作为下个迭代周期的依据。

        3.  新速度是上一个迭代周期完成的实际点数。

    10. 将迭代与管理阶段联系起来

        1.  “统一过程”项目的四个管理阶段：

            1.  初始阶段

                确定系统的可行性和商业案例。

            2.  细化阶段

                确定系统架构并创建一个比较可靠的实现计划。

            3.  构造阶段

                开始进行系统实现。

            4.  移交阶段

                安装系统，和用户一起测试（UAT测试）。

    11. 一个迭代周期中包括了：

        1.  分析需求

        2.  设计解决方案

        3.  实现解决方案

            只考虑当前迭代期间需要处理的User Story。

    12. 结对开发

        两个开发人员用同一台机器工作，一起处理他们负责的任务。

    13. 可验收测试

        1.  每个迭代周期开始时，客户和QA一起把User Story充实到Use Case，并为之编写可执行的验收测试案例。

        2.  对于程序员验收测试案例就是需求文档。

        3.  整个迭代周期中，程序员持续的运行测试案例，以保证能正确的通过验收测试。

    14. 单元测试

        1.  代码未动，测试先行。

        2.  如果有任何一个单元测试没有通过，就不能编写新的产品代码。

        3.  极限迭代的过程：

            1.  先写一段5到10行的单元测试代码。

            2.  然后为了使这段单元测试代码能够编译通过，开始编写并不断充实产品代码。

            3.  一旦单元测试通过之后，就可以添加新的代码，开始新的迭代。

            4.  一个测试周期通常是1到10分钟。

        4.  极限迭代的目的：

            无论现在进展到什么程度，几分钟前的产品代码总是可以运行的。

        5.  单元测试也是文档的一种形式。

        6.  单元测试代码提供的信息有：

            1.  如何去调用一个特定的API。

            2.  如何创建一个特定的对象。

        7.  这种形式的文档是明确的，准确的，可编译的和可执行的。

    15. 重构：

        1.  只要用大量的单元测试和验收测试作靠山，就可以放心大胆的去修改那些需要修改的任何部分。

        2.  在不改变程序的行为的前提下，改进程序的内部结构就是重构。

        3.  每小时左右的编程结束后，就是几分钟小碎步式的重构，然后测试。

        4.  绝不能把烂代码留到第二天。

    16. 开放式办公环境：

        1.  成员之间有着非常频繁的交流和沟通，可以快速的互相提问，得到最快的响应和建议。

            做到互相依靠，互看代码。

            方便结对编程。

    17. 持续集成：

        1.  check in的规则：

            只有通过单元测试和验收测试的代码才能check in。

        2.  持续性的集成可以避免项目进度到了尾声才来一个非常庞大的终极集成。

    18. 文档：

        1.  Martin文档第一要律：

            只编写那些真正需要的有意义的文档。

        2.  不需要专门用类图来捕获所有的需求。

        3.  不需要在序列图里捕获所有的Use Case。

        4.  只有真正需要使用这些工具的时候才使用，否则就让它们一边歇着去。

8. 第八章 包（Packages）P92

    1.  Java的两类重要的包：

        1.  源代码包。package

        2.  二进制组件。.jar

    2.  Java Packages

        1.  Java Packages是名称空间（Name Spaces）

            它们允许程序员创建小的私有空间，以便在其中声明类。

            这些类的名字不会与其它包中同名的类发生冲突。

        2.  UML中表示一个包的几种方式：

            1.  包的图标是一个矩形框，在其顶部有一个标签，像一个文件夹。

                完整的包名显示在矩形框中间。

                P92 Figure 8-1

            2.  也可以将完整的包名写在矩形框上的标签中。

                剩下大的矩形框中列出包中定义的所有类。

                P92 Figure 8-2

            3.  可以使用包含关系（contains）显示包的嵌套结构。

                P93 Figure 8-3

        3.  依赖（Dependencies）

            在同一个包中的代码常常依赖另一个包中的代码。

            在UML中用依赖关系（dependency）表示这种依赖性。

            P93 Figure 8-4

            import不会创建真正的依赖关系，只有调用函数才会创建依赖关系。

    3.  二进制组件.jar文件（Binary Components）

        1.  UML中表示一个.jar组件的方式

            P94 Figure 8-5

        2.  一个组件常常包含一个或多个包，所以组件之间的依赖关系通常是包之间依赖关系的子集。

    4.  包设计的原则（Principles of Package Design）

        1.  遵循原则的作用：

            1.  易变的类放在一起。

            2.  将因为各种原因需要被改变的类分离开。

            3.  将经常改变的类和不常变化的类独立开。

            4.  分离系统的高层结构和底层实现细节。

        2.  发布/重用等价原则（The Release/Reuse Equivalency Principle）（REP）

            1.  被重用的一组类应该放到一个包中。然后这个包被那些重用它们的开发人员发布和跟踪。

            2.  创建一个包是为了方便别人重用。

            3.  重用的粒度就是发布的粒度。

                重用的最小的东西，是值得别人去发布和跟踪的。

        3.  公共闭合原则（The Common Closure Principle）（CCP）

            1.  CCP相当于OOD的单一责任原则（SRP）

            2.  由于相同原因要被修改的类放在一个包中。

        4.  公共重用原则（The Common Reuse Principle）（CRP）

            1.  CRP相当于OOD的接口隔离原则（ISP）

            2.  应该尽可能地将只被一个客户使用的包与被多个不同客户使用的包分开。

            3.  避免对包中某个类的修改会影响到其它没有使用该类的客户。

        5.  非循环依赖原则（The Acyclic Dependencies Principle）（ADP）

            1.  包的循环依赖将导致编译和开发方面的问题。

            2.  应避免在依赖图中出现循环依赖。

            3.  可以使用JDepend等工具，来检查是否存在循环依赖。

        6.  稳定依赖原则（The Stable Dependencies Principle）（SDP）

            1.  包不应该依赖那些比它们自己更不稳定（更易改变）的包。

            2.  每个包所依赖的包应当比依赖它们的包更稳定。

            3.  如果一个包有多个指向它的依赖，而它自己又依赖一个易发生改变的包，其结果就导致这个包很难改变。

        7.  稳定抽象原则（The Stable Abstractions Principle）（SAP）

            1.  SAP相当于OOD的开放－封闭原则（OCP）

            2.  为了保证稳定的包易被控制，稳定的包应该是抽象的。

                越稳定的包应该越抽象。

                抽象类和接口的比例越大的包就越抽象。

            3.  SDP原则和SAP原则相结合就成了包版本的依存关系倒置（DIP）原则。

            4.  结合SDP原则和SAP原则可得出：

                1.  稳定性随指向它的依赖的增多而增加。

                2.  抽象性应该随稳定性的增加而增加。

                3.  所以，抽象性应该随指向它们的依赖的增多而增加。

            5.  包依赖图对于解决依赖循环问题和判断编译顺序都很有帮助。

9. 第九章  对象图（Object Diagrams） P98

    1.  UML对象图就像系统运行时的一个快照。

    2.  对象图包含的信息有：

        1.  系统在某个特定时刻，或者系统处于某个特定状态时的内部结构。

        2.  对象和关系被实际使用的方式。

        3.  系统根据不同输入的变化情况。

    3.  对象图被使用的情况很少。

    4.  对象图所用的标记与类图相同。

    5.  对象图的另一个有用之处是在多线程系统中。

        1.  主动对象（Active Object）

            用粗线条框表示。

        2.  主动对象就像是线程的控制者。

            它们包含有控制线程的方法，如：Start、Stop、SetPrioring等。

            P102 Figure 9-4

    6.  在多线程系统中，对象图比类图更具有表达力的原因：

        这段程序结构是在运行时建立的，这是一种关于对象的结构而不是关于类的结构。

    7.  很多对象图能从类图直接推断出来，所以对象图应用的比较少。

10. 第十章  状态图（Stat Diagrams）P103

    1.  状态转换图（State Transition Diagrams）（STD）

        P103 Figure 10-1

        1.  状态

            使用圆形拐角矩形表示。

        2.  状态的名字

            放在圆形拐角矩形上面的框格中。

        3.  进入或退出状态时触发的动作。

            放在圆形拐角矩形下面的框格中。

        4.  状态之间的转换

            使用箭头表示，箭头指向表示从原状态到目标状态。

        5.  状态转换箭头上标记：

            1.  触发转换的每一个事件的名称。

            2.  当转换被触发时执行的动作。

        6.  初始伪状态（Initial Pseudo State）

            使用实心的黑色圆圈表示。

            标明了有限状态机生命周期的起始状态。

        7.  超状态（Super State）

            超状态适用于有多个状态要用相同的方式响应某些相同事件的情况。

            画一个超状态把那些类似的状态括起来，然后只需从超状态画一个状态转换箭头，

            来代替从每一个状态画转换箭头。

            超状态的转换可以被子状态的转换重载。

            P106 Figure 10-5

            超状态和一般的状态一样有entry、exit和专用事件。

            注意：超状态和其子状态的事件调用顺序。

            P106 Figure 10-6

        8.  专用事件

            表示状态的圆形拐角矩形的下面框格中包含了多对事件和动作。

            事件和动作的书写形式：event/action

            两个标准的事件是entry和exit。

            可以自定义事件。

        9.  初始伪状态和结束伪状态。

            初始伪状态不需要有事件，但可以有一个动作。

            这个动作是在有限状态机被创建以后，第一个被调用的动作。

            转换到结束伪状态时的动作是有限状态机最后执行的一个动作。

        10. 有限状态机图的使用：

            对于日趋完善中（即频繁变更中）的系统，

            在文档中创建STTS（State Transition Tables）要好于使用STDS（State Transition Diagrams）。

            在开发和维护有限状态机方面，使用文本语言比图形更加简单。

 

　

--------------------------------------------------------------------------------

版权所有：UML软件工程组织 

　　这两天为一个初始状态是否可以有两条向外的转换给难住了。朋友说看看规范，我看了2.0的规范上说：

An initial pseudostate is shown as a small solid filled circle (see Figure 15.16). In a region of a classifierBehavior state

machine, the transition from an initial pseudostate may be labeled with the trigger event that creates the object; otherwise,

it must be unlabeled. If it is unlabeled, it represents any transition from the enclosing state.

这没有明确说明是否可以有两条。

　　在argouml的用户组和umlchina上发信，一个argouml的外国用户朋友回了信，可是全是长难句，只模模糊糊懂了些。

我把问题和信也贴在这里，有谁看了知道答案说一下：

　　argouml用户组的回信：

users@argouml.tigris.org

CC: umlchina@yahoogroups.com, nirvanax@tom.com, users@learndiary.tigris.org, iuking@163.com

From: "Dashing Meng" <learndiary_dashing@yahoo.com>  Add to Address Book  Add Mobile Alert

Yahoo! DomainKeys has confirmed that this message was sent by yahoogroups.com. Learn more

Date: Thu, 29 Dec 2005 01:18:42 -0800 (PST)

Subject: [UMLChina] Re: [argouml-users] ArgoUML told me,the initial state should has only one outgoing transition in a statechart diagram

   

Thanks for your answer very much.I understood most part of your answer except those very long sentence:),my english isn't well.

 

This is something I will model:

User(userID,userName)

Goal(goalID,goalName)

MyGoal(userID,goalID,goalState)

the relationship between User and Goal is :M:N,and MyGoal is the association class.

MyGoal has three states:processing,quited,finished.

 

People will join an existed goal,and write diary under a goal,like the operation model of http://www.43things.com

 

From a user's view,there are two ways he can create a new object of class MyGoal:a user join a goal directly without posting diary under it, and a user post an diary under a goal, when he do these,a new MyGoal's record will be insert into database and with the state:processing.

 

From the system's view,in fact,user join a goal is the operation like:

User.joinGoal(int GoalID),then a new MyGoal is created;

user post a diary under a goal is the operations below:

User.postDiary(int GoalID),and,if this is the first posting diary under this goal,this operation will call the previous operation:User.joinGoal(int GoalID).

 

So,in fact,the object of class MyGoal's creating is caused by User.joinGoal(int GoalID) only.

 

But,I am modeling a business model now and only from the user's view to do so,what do you think to treat this kind of things?

 

Thanks.

 

/Dashing Meng

Leif Holmgren <sm4rpq@amsat.org> wrote:

Hi!

As I have been tought and what I can make out of the UML standard the

initial state symbol is there just to show which of the other states the

object end up in when it is created. So there is no real transition from

the "initial state" and another state other than the one taken from the

big void when the object is created. The UML standard also specifies

that you can have only one initial state in each (sub)state-machine!

Unfortunately the UML standard is pretty messed up when it comes to

state machines so you have to read the text carefully to understand

this, and don't stop at the 1.4 standard as the newer ones are more

clear but still messy.

Exactly what are you trying to state with your model? Can your object

start off in one of two different states or are you treating the initial

state symbol as a state of it's own?

I would not model (or program for that matter) a class that have it's

object start off in two different states at all. I would instead create

an initial state (created) from which I immediately transit to one of

those that I really want to be in after initialization. When an object

has something that needs to be initialized at object creation time it

tends to be the same initialization no matter what lifecycle you want

the object to go through later on.

If you are just thinking of the initial state as a proper state you

just have to add an extra state and then two outgoing transitions from

that one (properly named and guarded of cource) and you are back on track.

/Leif

Dashing Meng wrote:

> Hi,All,

> There are two path from the initial state can enter the state call

> "Processing".But when I draw two outgoing transition from the initial

> state,The ArgoUML said:

> This Initial state has an invalid number of transitions. Normally

> Initial states have at most one outgoing transition.

> Defining correct state transitions is needed to complete the

> behavioral specification part of your design.

> To fix this, remove transitions by clicking on transition in the

> diagram and pressing the "Ctrl-Delete" key.

>

> So I added a Junction between the initial state and state

> "Processing".Is this way all right?

>

> Thanks.

>

> ------------------------------------------------------------------------

　　umlchina上的回答：

From: <alexzhang@...>

Date: Wed Dec 28, 2005  8:40 pm

Subject: RE: [UMLChina] Re: ArgoUML told me,the initial state should has only one outgoing transition in a statechart diagram  alexzhang@...

 Send Email 

Hi Dashing,

I think this quesiton is tool  independent. You should refer to the state chart specification to see how it is prescribed in UML.

I urgently recommend we should learn from UML specification as the root cause.

 

 

Regards,

 

Alex Zhang

___________

GDNT, G124

ESN: 554-8782

-----Original Message-----

From: UMLChina@yahoogroups.com [mailto:UMLChina@yahoogroups.com] On Behalf Of Dashing Meng

Sent: Wednesday, December 28, 2005 8:36 PM

To: UMLChina@yahoogroups.com

Subject: RE: [UMLChina] Re: ArgoUML told me,the initial state should has only one outgoing transition in a statechart diagram

But,is there anyone can answer my question? If a initial state can has outgoing transition more than one in a state diagram?

http://learndiary.tigris.org/source/browse/learndiary/old/documentatio

n/easy_diary/design/pictures/MyGoalInfoStateChart.gif?

rev=1.1&view=markup

I am a UML self-learner,please tell me all the errors of mine.

Thanks a lot.

Dashing Meng <learndiary_dashing@yahoo.com> wrote:

ArgoUML is 100 percent free open source UML tool,it has been developing for 10 years,the main reason I using it in our open source project-LearnDiary is the spirit of ArgoUML developing Team.

Because we use a UML tool only for open source non-commerial developing for learning purpose.So we don't need a very powerful commerial UML tool.

In fact,I found ArgoUML is a little hard to use at first,but after using it some days,I have known some little skills for avoiding its defects and do some model with ArgoUML happily.

Thanks for introducing Visual Paradigm for UML for all of us.

Alex Guo <Alex.Guo@BenQ.com> wrote:

Hi, everyone

脗 脗 脗  Have you try Visual Paradigm for UML, it芒鈧劉s a perfect tool for draw UML diagram.

 

 

 

 

 

-----------------

Alex Guo

2005

--------------------------------------------------------------------------------

From: UMLChina@yahoogroups.com [mailto:UMLChina@yahoogroups.com] On Behalf Of Dashing Meng

Sent: Wednesday, December 28, 2005 4:01 PM

To: UMLChina@yahoogroups.com

Subject: RE: [UMLChina] Re: ArgoUML told me,the initial state should has only one outgoing transition in a statechart diagram

 

All is in http://argouml.tigris.org

Here is its last version of all things:include source,binary distribution,user manual,etc..

:http://argouml-downloads.tigris.org/argouml-0.20.ALPHA_4/

alexzhang@gdnt.com.cn wrote:

Hi

Dou you have the User Guide to ArgoUML?

Regards,

 

Alex Zhang

___________

GDNT, G124

ESN: 554-8782

-----Original Message-----

From: UMLChina@yahoogroups.com [mailto:UMLChina@yahoogroups.com] On Behalf Of learndiary_dashing

Sent: Wednesday, December 28, 2005 11:15 AM

To: UMLChina@yahoogroups.com

Subject: [UMLChina] Re: ArgoUML told me,the initial state should has only one outgoing transition in a statechart diagram

 

　　可能是我没有正确的表达自己的意思吧：)

ArgoUML有个模型正确性的自动判定功能，也就是他们说的：cognitive

support.

　　当我在状态机图的初始状态后面画了两条进入下一状态的转换线时，它告诉

我一般初始状态只能有最多一条向外的转换线。

　　于是，我在初始状态和下一状态间加了一个分支点：Junction,然后ArgoUML

就不报错了。状态机图见下：

http://learndiary.tigris.org/source/browse/learndiary/old/documentatio

n/easy_diary/design/pictures/MyGoalInfoStateChart.gif?

rev=1.1&view=markup

　　我想问：从ＵＭＬ规范来说，一个初始状态是不是只能有一条向外的转换

线？如果不能，假设我的真实的第一个状态有两条路径都可以进入，我怎样来表

达这种需求呢？

　　我没有在课堂上学过ＵＭＬ，用语不规范或其他的任何不当的地方还望给予

指出。

　　谢谢。

http://www.learndiary.com

http://develop.learndiary.com

LearnDiay Develop Group

--- In UMLChina@yahoogroups.com, ZhangChaoYang <from_mfc@y...> wrote:

>

> 他的意思可能是认为initState只是一个虚拟状态，不是真实存在的，所以要

定义一个真正的初始状态，比如idel状态

>

> Dashing Meng <learndiary_dashing@y...> wrote: Hi,All,

> There are two path from the initial state can enter the state

call "Processing".But when I draw two outgoing transition from the

initial state,The ArgoUML said:

> This Initial state has an invalid number of transitions. Normally

Initial states have at most one outgoing transition.

> Defining correct state transitions is needed to complete the

behavioral specification part of your design.

> To fix this, remove transitions by clicking on transition in the

diagram and pressing the "Ctrl-Delete" key.

>

> So I added a Junction between the initial state and

state "Processing".Is this way all right?

>

> Thanks.

>

　　

　　今天，向umlchina讨论组和argouml用户讨论组发了一封信，请教是否可以在一张活动图上画一个用例和用例的所有扩展。很高兴收到了argouml开发者mvw的回复。他的意见是可以这样做，并且详细解释了用例图中“包括”和“扩展”的关系。从中可以看出argouml开发社区对用户的真诚和友好。这愈发坚定了我使用argouml进行设计的决心。

　　附我的信件和mvw的回信：

From: "Michiel van der Wulp" <mvw@tigris.org>  Add to Address Book  Add Mobile Alert 

To: users@argouml.tigris.org

Date: Tue, 27 Dec 2005 09:28:35 +0100

Subject:  Re: [argouml-users] A question about drawing activity diagram for extends usecases

   

Hi Dashing,

 

Nice colourful diagrams!

 

>> Can I draw the activty diagrams of a usecase and

>> all its extends usecase in one activity diagram?

 

Yes. Since the extends are steps that only happen conditionally, it would be nice to show the condition in the diagram, too. You already did this in the other activity diagram in two ways: with a Junction state (the diamond), and with a Guard - I think both are OK. The junction slightly preferred if people that only know flow-charts have to read the diagrams.

 

One other remark on usecases, which seem to be confused by many, is the difference between include and extend.

An include is comparable with a subroutine: it is always executed, and (usually) only pulled out from the main usecase because it is common with other usecases. An extension is something that happens on a condition somewhere along the path.

 

Regards,

Michiel

 

----- Original Message -----

From: Dashing Meng

To: umlchina@yahoogroups.com ; users@argouml.tigris.org ; 炜 张

Sent: Tuesday, December 27, 2005 4:40 AM

Subject: [argouml-users] A question about drawing activity diagram for extends usecases

Hi,

  Can I draw the activty diagrams of a usecase and all its extends usecase in one activity diagram?here is my usecase diagram:

http://www.learndiary.com/pictures/easyDiary/easyDiaryUseCaseDiagram.gif

this is my activty diagram:

http://www.learndiary.com/pictures/easyDiary/PostADiaryactivityDiagram.gif

my unfinished ArgoUML0.18.1 model:

http://www.learndiary.com/pictures/easyDiary/easyDiary.zargo

 

thanks a lot.

UML中聚集(Aggregation)与组合(Composition)的区别

Posted on 2005-04-20 20:03 黄金狮子旗下 阅读(1199) 评论(8)  编辑 收藏 收藏至365Key 所属分类: UML设计 

书上是这样描述的：聚集是关联中的一种，聚集对象由部分对象组成；组合又是一种特殊的聚集。在一个组合对象中，部分对象只能作为组成对象的一部分与组合对象同时存在。

即是说，组合是“当聚集对象和它的组成对象之间是具有强关联的一种特殊聚集”，组合对象的关键特征是部分对象只能存在于组合对象之中，并且部分体的寿命可能比组合体短，但组合体消亡，部分体也必然消亡。

我们举例来说明：

聚集

电脑可以由显示器、CPU、主板、硬盘、键盘、鼠标等聚集而成。在这种关系里面，各个组成部分是可以分拆开独立存在的。

组合

衬衣是由主体、衣领、袖口、衣袖、钮扣等组合而成。在这种关系里面，衣袖或者衣领等如果拆分开来并不能算是一个独立的主体，不具有价值了。

树是由树干、树根、树枝、树叶等组合而成的。这里面树叶可以先于树消亡，但如果树被砍掉，那么树叶也没有存在价值了。

多数参考资料上都是上面叙述的那样解释的，不过我觉得理解起来还是有些难度：电脑我把他砸了，电脑坏了，那你说各个组成部分到底是一起消亡了还是没消亡呢？也许应该说至少没有被砸坏的部分还是可以独立使用的；可若这样说的话，那我衬衣破了个洞，我要把衬衣裁减为各个部分，那其他部分是不是也可以拿去拼装为新的衣服？

所以，后来我自己是这样理解的，不知道对不对，大家可以给我指正：同类的几个聚集对象里面的组成对象是可以互换的（比如电脑里面的配件）；而同类的几个组合对象里面的组成对象是不能够互换的（正所谓强关联嘛，所以这件衬衣的袖口换到另一件上面不科学；这棵树的叶子也没法装到另一棵树上面去）。

Feedback

# re: UML中聚集(Aggregation)与组合(Composition)的区别   

2005-04-20 21:03 by idior

这个概念一向分的不是很清楚。 很多大家也争论过 ， 没什么结果。

# re: UML中聚集(Aggregation)与组合(Composition)的区别   

2005-04-20 21:46 by neuhawk

好像去年高程考这个！

# re: UML中聚集(Aggregation)与组合(Composition)的区别   

2005-04-20 22:06 by 生活、工作

这样理解好像也不大对吧。

# re: UML中聚集(Aggregation)与组合(Composition)的区别   

2005-04-21 00:37 by 常建昭

我觉的这样理解是错的。。。

把电脑砸了(呵呵，想法不错。)，你的主板，CPU等还是独立的。。你不能把那些概念给想成物理上的消失，我认为那是种抽象的概念。。你可以把你举的树的例子引用进来，你把电脑砸了，零件还是有用的。。你砸的目标是电脑，而非个别零件。。

# re: UML中聚集(Aggregation)与组合(Composition)的区别   

2005-04-21 08:48 by 黄金狮子旗下

to 常建昭:

你说的是，我就是觉得那部分比较容易混淆，所以故意写成那样的。我真正的理解是下面最后一段嘛。

# re: UML中聚集(Aggregation)与组合(Composition)的区别   

2005-04-21 12:38 by 安琪儿

按照我的理解，上面举的两例似乎都应属于组合。

组合是强关联的聚集，电脑配件从一台电脑中分离出来后，仍然需要进行再次组装才能发挥作用。也可以这样理解组合，它是对所有部件的整合，相互依赖。即便此组合内部分割开来，若要有效，仍然会出现类似的彼组合。

再举个单纯的聚集的例子，一个班级有许多个独立的个体，当班级不存在时，个体仍能单独发挥个人作用。此时整体和部分就不遵从相互依赖的规则，是一种弱关联。

总之，聚集和组合主要体现在关联强度上的不同。

# re: UML中聚集(Aggregation)与组合(Composition)的区别   

2005-04-22 01:08 by 吴正杰

UML宝典上面说明：　生命周期不同

组合在聚集中用来说明部件的生存周期取决于整体即集合的生存周期。

# re: UML中聚集(Aggregation)与组合(Composition)的区别   

2005-05-04 15:58 by 无名

感觉这里边有一个应用环境的问题，就目前看，人的器官和人体之间是组合关系，那时因为器官移植技术还不够发达，如果将来器官移植技术发展了，器官和人体之间可能就成为组合关系了。

 UMLChina@yahoogroups.com

From: "Stephen Suen (SUNRUJUN)" <stephen.suen@gmail.com>  Add to Address Book  Add Mobile Alert 

Date: Mon, 5 Dec 2005 18:42:44 +0800

Subject: Re: 答复: 回复： [UMLChina] 业务对象模型(领域模型)的作用? 请教专家

    

业务建模的作用是为企业现有业务建立模型，需要的话，在此基础之上进行业务重组或者优化。业务模型将用作后续软件过程的输入。

 

实践中，通常我们会跳过业务建模的过程。当然，前提是我们认为业务建模是没有必要的。对于某些应用所面对的业务，其流程和涉及的实体可能是极其复杂的，软件工程人员无法轻易了解业务。此时，业务建模过程将有效地帮助软件工程人员理解业务（尤其是借助UML等图形工具的情况下），并使这些理解得到记录和整理。同样借助图形工具，比如时序图，状态图等，可以分析业务，需要的话，可以进行重组和优化。

 

对于业务建模，常见的两个问题是该做的时候没有作和不必要的时候却做了。

 

面对复杂业务，缺失业务建模过程使得软件工程人员根本不可能真正的理解业务，更加无法真正的理解用户需求，而是仅仅依赖用户的口述等获得大量似是而非的理解，最终导致大量的变更，甚至更严重的问题。如果进行业务建模，基于模型，你甚至会发现用户没有告诉过你的事物。更好的理解，意味着更好的沟通，进而更完善的需求。

 

另一个问题，是僵化的套用软件工程理论，在没有必要的情况下进行业务建模。对于一些简单业务，在全体人员可以轻易的理解业务的情况下，完全没有必要进行业务建模。有些组织为了诸如所谓"规范"等等理由而不是工程理由而要求这样的过程，反而会带来问题。因为业务建模和系统建模的过程具有传承关系，二者之间的一致性需要付出相当的代价。如果业务或者你的经验允许你直接进行系统建模，完全没有问题。当然，如果业务建模的文档可以卖出价钱的话，业务建模有相应的经济回报也未尝不可。

 

On 12/5/05, 赵鹏 <zhaopeng@webservice.com.cn> wrote:

是否可以认为"业务建模"，就是"整合业务""优化流程"的过程？！

 

--------------------------------------------------------------------------------

发件人: UMLChina@yahoogroups.com [mailto: UMLChina@yahoogroups.com] 代表 孙向晖

发送时间: 2005年12月5日 14:19

收件人: UMLChina@yahoogroups.com

主题: 回复： [UMLChina] 业务对象模型(领域模型)的作用? 请教专家

 

首先，业务建模并不是开发过程中必需的。

其次，业务建模的作用还是很大的，而现实操作过程中，我们（开发商）往往会忽略业务建模。

业务建模其实分为两个部分来看。一个部分是对as－is建模。另一部分是对to－be建模。as－is，是对企业或者机构等业务建模范围的业务现状建模，以找出其业务过程中实际存在的问题。注意：很多问题，是IT所解决不了的。我们的售前经常跟客户说，只要你能想到的，我们就能做出来。这本身一个很大的问题。企业运营过程中的很多问题，IT都解决不了，或者靠IT来解决，既费工又费力，IT之外，还有更多的更优的方案。所以，在这个方面，IT人士可以做的就是，圈定哪些问题需要由IT来解决，而且必须靠IT来解决的有哪些。

第2个部分，也就是to－be建模。是对企业将来的建模。当我们对企业的业务运营问题给出一个比较好的解决方案后，企业会是一个什么样的运行状况呢？企业不知道，我们也不知道，最好的办法，就是对to－be进行建模。企业应该按照最新的业务模式进行哪方面的业务重组呢？企业是否能够接受这样的业务模式呢？毕竟，业务重组的过程中会牵扯到方方面面人的利益，重组的结果有可能会失败。IT人士也应该把此列入风险中。

 

业务建模的好处：圈定系统边界，理解业务核心，有效掌控风险。

在业务建模的过程中，出来的工具可以做为系统需求（用例）的输入。它们之间有很好的映射关系。但是，这跟是否使用requisitepro工具无关。你甚至可以简单的excel建立自己的跟踪矩阵。。

rockhai2005 < rockhai2005@yahoo.com.cn> 写道：

一个项目,采用ROSE的RUP模版建模。已经确定用到业务用例,进而用到业务对

象模型。现在有一些疑惑，不太明了：业务对象模型到底有什么作用？

我已经了解到的作用如下：

** 对执行业务功能的对象和这些对象之间的关系进行建模，即进一步（或同

时）解释业务用例。这样做的好处是在机构的层面上，更好地就未来系统完成的功

能与客户和项目组成员（相关项目干系人STAKE HOLDER）沟通；

那么它的其它作用呢？比如

1.它是否对分析模型有指导作用？就象业务用例指导系统用例一样？对应关系

如何？

2.如果1中的答案是肯定的，那么这种对应关系在ROSE中是否也可以靠

RequisitePro 工具来实现映射？

------------------------ Yahoo! Groups Sponsor --------------------~-->

Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.

http://us.click.yahoo.com/KIlPFB/vlQLAA/TtwFAA/saFolB/TM

--------------------------------------------------------------------~->

Yahoo! Groups Links

<*> To visit your group on the web, go to:

http://groups.yahoo.com/group/UMLChina/

<*> To unsubscribe from this group, send an email to:

UMLChina-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:

http://docs.yahoo.com/info/terms/

　　今天，在自己的硬盘里发现一本介绍一本用uml建模java程序的好的电子书，名字是“Java 与 UML 面向对象程序设计”，英文名字是“The Essence of Object-Oriented Programming with Java And UML”，作者是：Bruce & Wampler，译者，看不清，人民邮电出版社。

　　这本书的主体讲的是用UML和MVC模式进行一个java的swing图形界面应用程序的建模。从基础的建模元素和java基础面向对象概念开始的。但其中提供的内容远远不止这些。这是一本讲软件开发生命周期的全过程的基本概念的书，涉及到程序员人的自身，是一本据有全局观念的书。

　　给我印象深刻的是如下：

　　１）、设计模式；

　　２）、软件开发方法，其中对各种的开发方法作了深入浅出的比较，包括RUP，敏捷联盟，XP编程，最后还说了开放源码开发方法；

　　３）、怎么样给程序员创造一个好的氛围，让大家愉快的工作和生活；

　　４）、其中，我最最感兴趣是关于软件重构的那一章，其中讲解了什么情况下需要重构，什么情况下没有必要重构。怎么样重构。学习日记也在面临这样的问题。

　　这本书我还会放在那里慢慢欣赏的。

下面是来自网上的介绍：介绍：http://www.dearbook.com.cn/book/viewbook.aspx?pno=TS007470

×××××××××××××××××××××××××××××××××××××××××××

     Java与UML面向对象程序设计

定价：28.00 元 | 售价：21.30 元(76折)      

--------------------------------------------------------------------------------

 | Bruce E.Wampler著 王海鹏译

人民邮电出版社  | 7-115-10603-7 | 2002年10月 | 开本:787*1092 1/16

版别版次:2002年10月北京第一版第一次印刷 |分类：程序设计→Java | 软件工程/软件技术→UML

--------------------------------------------------------------------------------

页数：208 阅读数：846销售排名：2488    库存情况:库存充足      

内容简介 |  图书目录 |  图书前言 |  查看评论(11 条)| 收藏此页到365Key

本书旨在介绍使用Java和UML开发面向对象的软件所必需的知识，并将伴您走上使用Java进行真正面向对象软件开发的道路。

    本书共分12章。本书的前4章介绍了面向对象的精髓，第1章是关于对象的简介。第2章介绍了面向对象的基本概念以及UML的一些基本知识。第3章阐述了如何使用Java来编写面向对象程序。第4章介绍面向对象的分析和设计。第5章使用这些面向对象观点分析了图形用户界面（GUI）和Java Swing类库。第6章以一个小规模的Java应用程序为实例，将前5章的内容结合到一起。

    接下来的章节让您对面向对象编程的实践方面有较好的了解。第7章介绍了设计模式。第8章介绍软件重构。第9章简要介绍针对大规模和小规模的面向对象软件项目以及当前的一些主要开发方法。第10章介绍当前一些面向对象软件开发的工具软件。第11章给出了作者为开发更好的软件而提出一些指导意见。最后，第12章提供了关于面向对象软件和Java方面更多的学习资源。

    本书强调理论和设计相结合，重视对软件开发方法学有指导作用的重要概念。本书可作为高等学校计算机科学系及软件学院高年级学生和研究生的教科书，也可作为从事软件开发的管理者、系统分析员、程序员在学习面向对象程序设计时的参考书。

《Java与UML面向对象程序设计 》相关文章和资源：

提交资源|本书引用地址：http://www.dearbook.com.cn/book/TrackBack.aspx?pno=TS007470

--------------------------------------------------------------------------------

Java类热销图书：

Expert One-on-One J2EE Development without EJB(中文版(JavaEye)

精通Struts：基于MVC的Java Web设计与开发(孙卫琴)

Effective Java中文版(潘爱民 /译)

Java2核心技术（第6版）卷I:基础知识(程峰 黄若波 章恒 /译)

Java编程思想（第2版）(侯捷 /译)

--------------------------------------------------------------------------------

名家评论：

练好面向对象的基本功——读《Java与UML面向对象程序设计》

(专家Seal Wang于2003-10-10 4:41:55)  0人同意、0人反对 

这是一本相当不错的入门级书籍，适合有一定Java基础、希望对面向对象编程有进一步了解的读者。就像《围棋一月通》一样，是一本介绍Java面向对象编程的必备常识性图书。书到今生读已迟。如果等到经历了许多痛苦和失败才明白一些常识（也许还不能明白），代价就太大了。这本书没有介绍软件开发领域的最新尝试，只是从一名老程序员的角度介绍了程序设计的一些宝贵常识和经验。这也正是我推荐此书的缘由。...查看详细 

对此评论 我同意  我反对    

正在读取本评论的讨论，请稍侯……

 

--------------------------------------------------------------------------------

 

读者评论： 共 11 条评论  发表评论  

 

[无题](读者 shuiying于2004-6-16) 0人同意、0人反对    

  这本书讲述对象的内容很不错，简单易懂，但关于JAVA的就逊色了。 

发表评论 我同意  我反对    

正在读取本评论的讨论，请稍侯……

 

 

 

[无题](读者 duckdl于2004-6-16) 0人同意、0人反对    

  就书的内容来讲应该是算不错的。但是如果读者是冲着这本书的题目去买的，那就没有必要了。值得一看，但不值得收藏，虽然讲得实在，但不觉得经典。倒是里面有一段用MVC来设计swing程序的篇章还是不错的 

发表评论 我同意  我反对    

正在读取本评论的讨论，请稍侯……

 

 

 

[无题](读者 wsqwsq于2004-6-16) 0人同意、0人反对    

  这本书我已经读完了。给我的感觉是：很适合大学在校生阅读。该书中介绍了当前主流的UML基础知识,模式的基本概念，MVC概念。比较适合入门。对JAVA本身没有过多地描述。 

发表评论 我同意  我反对    

正在读取本评论的讨论，请稍侯……

 

 

 

[无题](读者 charity于2004-6-16) 0人同意、0人反对    

  书的内容涉及广度不错，非常适合入门。

  译得也不错，总的评价：一本值得购买的书 

发表评论 我同意  我反对    

正在读取本评论的讨论，请稍侯……

 

 

 

[无题](译者 sealw于2004-6-16) 0人同意、0人反对    

  这是一本相当不错的入门级书籍，适合有一定Java语言基础，希望对面向对象编程有进一步了解的读者。

 

  本书对一些面向对象程序设计和Java的基本概念讲述得很清楚，对我来说印象深刻的有MVC，深拷贝与浅拷贝等等。尤其是结合实例分析的MVC，让我们看到上世纪80年代通过Smalltalk所发展起来的面向对象程序设计结构上的自然和优雅。

 

  本书结合例子展示了UML的使用，但是是以类图为主，并没有太侧重在整个设计过程中使用UML的各种图，可能也是基于本书的目标读者的考虑。希望对UML了解更多读者，可以参考其它读物。书中给出了许多进一步学习的资料。

 

  本书的另一个好处是，作者基于多年的编程经验和对目前软件开发实践的理解，为软件开发的入门级读者介绍了设计模式，重构，软件开发方法学等方面的知识，为读者的进一步学习指明了一些方向。本书对程序开发的工具软件，特别是选择编辑器方面的介绍，也相当有意思。

 

  作者在第11章所介绍的对软件开发的一些个人理解，应该能引起有经验的程序员的共鸣。

 

  与另一本书《UML面向对象程序设计基础》（Meilir Page-Jones著，人民邮电出版社）相比，这本书的难度要低一些，覆盖面要广一些。

 

  在对面向对象编程领域的经验不超过5年的程序员，在这本书中应该都可以学到一些东西。本书也适合作为培训教程。 

发表评论 我同意  我反对    

正在读取本评论的讨论，请稍侯……

 

 

--------------------------------------------------------------------------------

更多评论

 

发表评论 您现在匿名评论。 我要登陆评论

身份： 读者 译者 作者 出版商

 

标题： 

 

 

 

 

 

　不表态

  中肯取代无礼 　 客观代替漫骂 　

 (您的精彩评论会被14位书友会会员收到)   

 

--------------------------------------------------------------------------------

《Java与UML面向对象程序设计》图书目录：

第1章 对象、UML和Java 1

1.1 面向对象技术 2

1.2 面向对象程序设计语言 3

1.3 面向对象的设计和UML 3

1.4 对象的回报 4

1.5 本章小结 4

第2章 对象的精髓 5

2.1 什么是面向对象系统 6

2.1.1 面向对象系统的基本特性 7

2.1.2 利用对象进行抽象 8

2.1.3 封装的类 9

2.1.4 通过消息进行通信 9

2.1.5 对象生命周期 10

2.1.6 类层次结构 12

2.1.7 多态性 16

2.2 一个例子：体现前面所讲的概念 18

2.3 其他面向对象概念 19

2.3.1 抽象类 19

2.3.2 方法的可见性 20

2.3.3 类与实例 21

2.3.4 访问对象 22

2.3.5 对象的低层次视图 22

2.4 本章小结 23

2.5 参考资源 24

2.6 本章注释 24

第3章 Java中的对象 25

3.1 在Java中定义类 25

3.2 可见性 29

3.3 继承 31

3.4 关联、聚合与组合 37

3.5 Java接口 39

3.6 Java中对象的生命周期 41

3.6.1 构造方法 41

3.6.2 垃圾收集 41

3.6.3 内存泄漏 42

3.7 类方法、类属性与实例方法、实例属性 42

3.8 对象拷贝 43

3.9 消息 49

3.10 本章小结 49

3.11 参考资源 50

3.12 本章注释 50

第4章 面向对象的分析和设计 51

4.1 软件开发方法学 53

4.2 软件项目的要素 54

4.3 面向对象分析的精髓 56

4.3.1 对象发现 57

4.3.2 评估候选对象 58

4.3.3 确定对象层次结构 60

4.3.4 发现对象属性 61

4.3.5 发现对象操作 61

4.4 对象设计精髓 63

4.5 一些设计指南 65

4.5.1 从整体上把握 65

4.5.2 封装 66

4.5.3 设计类 66

4.5.4 继承 67

4.5.5 通用指南 67

4.6 建造和发布阶段 68

4.6.1 建造软件 68

4.6.2 发布软件 69

4.7 UML的更多知识 70

4.8 本章小结 71

4.9 参考资源 72

4.10 本章注释 72

第5章 用Swing实现面向对象的图形用户界面 73

5.1 图形用户界面 74

5.1.1 典型应用程序 74

5.1.2 对话框 74

5.1.3 事件 75

5.2 Swing简介 76

5.2.1 处理Swing命令事件 79

5.2.2 一些选项 85

5.3 MVC：模型/视图/控制器 86

5.3.1 用Java实现MVC 87

5.3.2 一个小的Swing MVC GUI框架 88

5.3.3 一个基于Wmvc的简单应用程序 98

5.3.4 温度计的UML时序图 103

5.4 本章小结 104

5.5 参考资源 104

5.6 本章注释 105

第6章 使用Java的实例研究 107

6.1 分析MovieCat 108

6.1.1 用况 108

6.1.2 发现对象、属性和操作 109

6.1.3 评估 111

6.2 设计MovieCat 111

6.2.1 Movie类 112

6.2.2 MovieModel类 114

6.2.3 视图类 115

6.2.4 将它们结合起来 117

6.3 实现MovieCat 117

6.3.1 MovieCat类 117

6.3.2 Movie类 119

6.3.3 MovieModel类 121

6.3.4 MainView类 125

6.3.5 MovieListView类 129

6.3.6 MovieItemView类 131

6.3.7 MovieEditor类 135

6.3.8 Movie的辅助类 138

6.4 回顾 141

6.5 本章小结 142

6.6 本章注释 142

第7章 设计模式 143

7.1 什么是设计模式 143

7.1.1 使用设计模式 144

7.1.2 设计模式描述模板 144

7.2 GoF设计模式 145

7.2.1 创建型模式 145

7.2.2 结构型模式 145

7.2.3 行为型模式 146

7.3 Wmvc和MovieCat使用设计模式的例子 147

7.3.1 MVC 147

7.3.2 Observer模式 148

7.3.3 Wmvc中的Observer模式 150

7.3.4 Wmvc中的Command模式 151

7.3.5 Wmvc和MovieCat中用到的其他模式 152

7.4 本章小结 152

7.5 参考资源 152

第8章 重构 153

8.1 什么是重构 154

8.1.1 基本重构过程 154

8.2 何时需要重构 155

8.2.1 代码味道 155

8.2.2 何时不要重构 156

8.3 一些重构技术 156

8.3.1 重构分类 156

8.3.2 一些重构技术 157

8.4 本章小结 158

8.5 参考资源 158

第9章 今日软件开发方法学 159

9.1 大规模项目适用的方法学 160

9.1.1 统一软件过程概述 160

9.1.2 基本概念 160

9.2 适用于小项目的敏捷方法学 162

9.2.1 敏捷联盟 162

9.2.2 极限编程 163

9.2.3 DSDM 165

9.2.4 Crystal/Adaptive软件开发方法 166

9.3 开放源代码开发 166

9.3.1 开放源代码是分布式开发 167

9.4 本章小结 168

9.5 参考资源 168

9.6 本章注释 169

第10章 面向对象开发的软件工具 171

10.1 GUI与控制台 171

10.2 编辑器和IDE 172

10.2.1 好编辑器的特征 172

10.2.2 三种类型的编辑器 173

10.2.3 Emacs 174

10.2.4 Vi 174

10.2.5 集成开发环境 175

10.2.6 VIDE 176

10.2.7 Borland JBuilder 176

10.2.8 Sun Forte 178

10.2.9 其他IDE 179

10.3 源代码控制 179

10.4 CASE、建模和UML工具 179

10.4.1 ArgoUML 180

10.4.2 MagicDraw 180

10.4.3 Rational软件公司 181

10.4.4 TogetherSoft 181

10.4.5 其他UML工具 181

10.4.6 其他Java工具 182

10.5 本章注释 182

第11章 编程：个人观点 183

11.1 编程 184

11.1.1 代码不会消亡 184

11.1.2 用好的风格编程 185

11.1.3 清楚自己在做什么 185

11.1.4 写试验性代码 185

11.1.5 实践增量编程 186

11.1.6 工具很重要 186

11.1.7 对象确实有帮助 186

11.1.8 测试 186

11.1.9 调试 187

11.1.10 不要重新发明轮子 187

11.1.11 有时自己做更好 187

11.1.12 任何时候都可能产生好主意 188

11.1.13 拥有生活 188

11.1.14 计划很重要 188

11.2 工具 189

11.2.1 编辑器很重要 189

11.2.2 了解经时间检验的工具 189

11.2.3 了解最新的工具 189

11.2.4 工具会消失 189

11.3 工作环境 190

11.3.1 快乐的程序员是高效的程序员 190

11.3.2 物理环境 190

11.3.3 灵活性 190

11.3.4 40小时 191

11.3.5 团队 191

11.3.6 市场营销很重要 191

11.3.7 保持不过时 192

11.3.8 共同奋斗 192

11.3.9 让程序员协助制定策略 192

11.3.10 让老板知道您需要什么 192

11.3.11 Reference软件公司的故事 192

11.4 编程资源 193

11.4.1 使用互联网 193

11.4.2 当心互联网 193

11.4.3 如果可能，用开放源代码 193

11.4.4 其他程序员 193

11.4.5 网站 194

11.5 本章注释 194

第12章 下一步 195

12.1 面向对象技术 195

12.2 Java 196

12.3 需要了解的更多术语 196

12.3.1 分布式计算术语 196

12.3.2 来自Sun公司的Java相关术语 197

12.3.3 其他术语 198

词汇表

At last,I finished UML model of fileSharing system with ArgoUML.Struts+Hibernate were taken.After finishing this model,I felt there are some diagrams seemed redundant.And,maybe,this software engineering process isn't proper for a framework and component based software.This will need friends to evaluate this model.

At this point,ArgoUML there are only basic UML function(the sequence diagram was imported in not long ago and doesn't work well.)But,I think learning UML with it is enough.And,according to the status of it,I think it will grow to a useful UML tool at last.

 MOF以及MOF四层结构的理解（2）

2005-06-30 10:43:41 The(158587432)

请阁下给出keven->人?>?的答案

2005-06-30 10:43:51 The(158587432)

我就卡在这个关头了！

2005-06-30 10:44:06 keven(184014384)

我还是希望你可以自己悟到。

2005-06-30 10:44:12 The(158587432)

难悟啊！

2005-06-30 10:51:07 中国幽剑软件(465572013)

谢谢了，终于找到头绪了

2005-06-30 10:51:11 The(158587432)

我钻进死胡同了，感觉出不来了，脑袋也晕掉了

2005-06-30 10:51:35 keven(184014384)

你们两个感觉完全相反哦。

2005-06-30 10:52:19 The(158587432)

不是吧，他先前也认为我说keven->人?>物种是对的

2005-06-30 10:52:23 中国幽剑软件(465572013)

因为我喜欢简单，再复杂的东西我都喜欢找一种简单的例子来说明它，呵呵........

2005-06-30 10:52:39 中国幽剑软件(465572013)

好像我没有说吧？

2005-06-30 10:53:38 keven(184014384)

那我说了。

2005-06-30 10:54:02 The(158587432)

这样说的话，"元"就表示"如何"构建，"物种"这个概念是表明了如何构建"人"这个"物种"，而"人"又表明了如何构建"keven"。是这样的啊？

然后，你说“对头‘

2005-06-30 10:54:45 中国幽剑软件(465572013)

我说的对头是指keven说的要实际应用，呵呵.......

2005-06-30 10:55:27 The(158587432)

[:L]

2005-06-30 10:55:48 The(158587432)

下午再来，现在要去吃饭，并且休息一下，我已经脑袋很痛了！！！！

2005-06-30 10:56:10 keven(184014384)

其实很简单：

keven

人（类）

类(UML)

类元(MOF)

2005-06-30 10:57:01 中国幽剑软件(465572013)

不用头痛，“对象”这个词我理解了两年才真正弄明白它的内涵呢

2005-06-30 11:04:17 keven(184014384)

呵呵，答案出来了，人也跑了。

2005-06-30 11:05:22 中国幽剑软件(465572013)

现在我不说我明白了，等我有机会把它正确的扔到我的图里的时候，才说明我明白了.....

2005-06-30 11:05:38 keven(184014384)

呵呵，有志气。

2005-06-30 11:07:02 中国幽剑软件(465572013)

我说了，我今天开始学习UML（理论以前看过）和Plato，我今天就开始用它做项目，错误和更好的方法少了还得keven指教了.........

2005-06-30 11:07:44 keven(184014384)

好的。

2005-06-30 11:09:21 中国幽剑软件(465572013)

暂时潜水，玩玩VC，没有实现的经验设计出来的东西可能不好用的.........呵呵..........

2005-06-30 14:28:53 The(158587432)

下午来报道！

 

2005-06-30 14:30:06 webmaster(344593239)

现在想明白了吧？

2005-06-30 14:30:28 The(158587432)

没想明白

2005-06-30 14:31:20 webmaster(344593239)

嗬嗬，可惜早上keven说答案的时候，你已经走了

2005-06-30 14:33:25 The(158587432)

就先前中午睡觉，脑袋痛，迷糊的很，云里雾里感觉到人后面应该是类，也算沾边了不少。但是刚刚看到，keven说类后面是类元，那翻译过去就是classifier，关于classifier，uml参考手册上是这么说的：a model element that describes the behavioral and structural features.

2005-06-30 14:34:23 The(158587432)

类元包括类，actor，component，等等，这不是混淆了吗？那构造型到底扩展的是第几层》？

2005-06-30 14:34:45 The(158587432)

头痛啊~~~

2005-06-30 14:37:27 keven(184014384)

首先搞明白：为什么类是人（类）的元？

2005-06-30 14:37:41 The(158587432)

uml参考手册里面说association is the semantic relationship that two or more classifiers that involves connection among their instances.

这不就是classifier是元模型层

2005-06-30 14:38:35 The(158587432)

类是人的元，我在感觉上已经赞同了，精确的表述出来，我还要想想

2005-06-30 14:39:09 The(158587432)

uml参考手册竟然不能复制，要手敲英文！

2005-06-30 14:40:55 The(158587432)

我的理解：类应该是具有属性集和方法集的整体，而人这个类具体讲明了属性集里有哪些属性，方法集里有哪些方法，实例化了属性集和方法集

2005-06-30 14:41:02 The(158587432)

对不？

2005-06-30 14:42:45 keven(184014384)

呵呵，对啦。

2005-06-30 14:43:02 keven(184014384)

终于有些明白了。

2005-06-30 14:43:23 The(158587432)

类元解释不过去啊，就我刚说的那些问题

2005-06-30 14:44:25 keven(184014384)

我这里的类元不是UML里的类元，而是MOF里的类元。

2005-06-30 14:44:54 The(158587432)

哦？~难怪

 

2005-06-30 14:45:25 keven(184014384)

MOF里的类和UML里的类名字一样，概念却完全不一样：MOF里的类是UML里的类的元数据，即定义了UML里的类；

而MOF里的类由谁定义呢？

2005-06-30 14:46:03 The(158587432)

好象错开了一个层次

2005-06-30 14:46:15 The(158587432)

这些个老外，写文挡也不致意一致！

2005-06-30 14:46:34 keven(184014384)

告诉我，MOF里的类的元数据是谁？

2005-06-30 14:47:03 The(158587432)

那在uml里，classifier和metacalss是不是一回事情

2005-06-30 14:47:23 The(158587432)

MOF里的类的元数据？我先查查术语啊

2005-06-30 14:48:04 keven(184014384)

现学现卖？

2005-06-30 14:48:34 The(158587432)

是啊，中午头痛的很，睡觉去了，睡觉中，还迷糊地在想这些个问题呢

2005-06-30 14:49:08 keven(184014384)

呵呵

2005-06-30 14:49:23 The(158587432)

类元啊

2005-06-30 14:50:00 The(158587432)

那在uml里，classifier和metaclass是不是一回事情

？

2005-06-30 14:50:10 keven(184014384)

又错了。

M1定义M0,

M2定义M1，

M3定义M2

那么谁定义M3？

2005-06-30 14:50:19 The(158587432)

M4

2005-06-30 14:50:45 keven(184014384)

那岂不无限了,M10000...

2005-06-30 14:50:48 The(158587432)

等等，本来就只四层，说到M4，似乎又错了，那就没得去定义

2005-06-30 14:51:08 The(158587432)

我也刚刚发现这个问题

2005-06-30 14:52:22 keven(184014384)

metaclass可以认为是MOF层的类。

而Classifier是UML层的类的父类。

不一个层次。

2005-06-30 14:52:37 keven(184014384)

M3定义自身。呵呵。

2005-06-30 14:53:24 The(158587432)

想一分钟~

2005-06-30 14:56:23 The(158587432)

不是 ，uml手册里面写的：metaclass:a class whose intances are classes

2005-06-30 14:56:50 keven(184014384)

呵呵。

所谓元：就是实例和类的关系。instance

2005-06-30 14:56:58 The(158587432)

这不明确表示metaclass是类的父类？

 

2005-06-30 14:57:22 keven(184014384)

实例和泛化是两个概念。

2005-06-30 14:57:41 The(158587432)

精髓啊！！！！

2005-06-30 14:58:09 The(158587432)

好象有点悟了~~~

还差术语通关！

2005-06-30 14:58:09 keven(184014384)

明白了？

2005-06-30 14:58:11 The(158587432)

谢谢

2005-06-30 14:59:15 /catAcaT/cat(367021)

我是来拜2位牛人了，受我253一计，hoho

2005-06-30 15:00:44 The(158587432)

实例化即为赋值，泛化即为扩展~

对不？

2005-06-30 15:01:13 keven(184014384)

赋值？？？

2005-06-30 15:01:43 The(158587432)

我是这样想的啊

2005-06-30 15:02:17 keven(184014384)

实例就是类和对象的关系。

2005-06-30 15:03:21 The(158587432)

我的意思是赋值是实例化的过程，就像实例化一个类，先是构造建立一个空的未初始化对象，然后对其进行每项赋值

2005-06-30 15:03:34 The(158587432)

我认为就这样

2005-06-30 15:03:56 keven(184014384)

呵呵。

2005-06-30 15:05:46 The(158587432)

就像先前说的类和人，人就对类的属性集和方法集在它们未初始化后进行赋值。先建造容器，再填充

2005-06-30 15:06:21 keven(184014384)

呵呵，大家都明白了。

2005-06-30 15:06:46 The(158587432)

元赋予了容器的语义，而下一步操作就是根据这个语义和实际应用需求进行填充

2005-06-30 15:07:19 The(158587432)

这里的容器就是一个概念，只有装满了东西，才能够成为真正的实例

2005-06-30 15:07:28 The(158587432)

你是说我明白了？

2005-06-30 15:07:33 The(158587432)

[:D]

2005-06-30 15:07:41 keven(184014384)

[strong]

2005-06-30 15:07:54 The(158587432)

谢谢您的指点！

2005-06-30 15:08:32 The(158587432)

我想我刚说的赋予和扩展是分辨这两个关系的好切入点

2005-06-30 15:08:39 keven(184014384)

呵呵，没事。实践三个代表，人人有责。

2005-06-30 15:11:05 The(158587432)

能再问两三个关于很实际的术语方面的问题吗？不知道是否耽误您的时间。

敬上！

2005-06-30 15:11:18 keven(184014384)

说。

2005-06-30 15:11:48 The(158587432)

那我就一鼓作气把问题搞懂了。谢谢

2005-06-30 15:12:39 The(158587432)

stereotype扩张的是元模型层对吗？

2005-06-30 15:13:33 The(158587432)

我说的是uml中的概念，都不涉及MOF

2005-06-30 15:13:36 keven(184014384)

对，可以认为和UML类同级的兄弟。

2005-06-30 15:14:10 The(158587432)

那profile就是一个充满构造型的包包？

2005-06-30 15:15:04 The(158587432)

在uml的概念范围中，classifier和metaclass应该是同一个概念？

 

2005-06-30 15:15:08 keven(184014384)

还有标记，约束。

2005-06-30 15:15:30 The(158587432)

呵呵，记住了

2005-06-30 15:16:00 keven(184014384)

在uml的概念范围中，classifier和metaclass不是同一个概念。刚才已经解释过了。

2005-06-30 15:20:35 keven(184014384)

一个定义结构：元。

一个定义数据：泛化。

2005-06-30 15:21:39 The(158587432)

大三了，毕业不考研，希望到你们公司工作。我会努力的！

2005-06-30 15:24:46 The(158587432)

不是，我觉得你们楚凡，感觉起来是一帮子实打实的人，而且名字上又有个“楚”字，我是湖南人呢。

跟这样的一群人打交道，感觉很好

 

 

 

我是www.trufun.net站长!

 

 本贴发表时间：2005-7-2 11:02:08

 

ArgoUML0.19.2 can't open the file created by ArgoUML0.18.1.It hited my heart again.Although,I am very like ArgoUML,but,my main goal is to learn UML,not a tool.If this tool has stop my learning UML and our project,I have to discard it saddly.

The real goal of ArgoUML is practicing technique,or proffering it to general user?

I think,a software is a good software only if it is used by many special user.