app-umlccw2.htm

一些UML和软件工程导论的资料

      </dd>
      <dd>&nbsp;&nbsp;&nbsp; </dd>
      <dd>&nbsp;&nbsp;&nbsp; 
        请注意扩展与使用之间的相似点和不同点。它们两个都意味着从几个用例中抽取那些公共的行为并放入一个单独用例中，而这个用例被其他几个用例使用或扩展。但使用和扩展的目的是不同的。</dd>
      <dd>　</dd>
      <dd>(5) 用例模型的获取 </dd>
      <dd>&nbsp;&nbsp;&nbsp; 
        几乎在任何情况下都会使用用例。用例用来获取需求，规划和控制项目。用例的获取是需求分析阶段的主要任务之一，而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生，并且随着工作的深入会发现更多的用例，这些都应及时增添到已有的用例集中。用例集中的每个用例都是一个潜在的需求。 
      </dd>
      <dd>　</dd>
      <dd>a. 获取执行者 </dd>
      <dd>获取用例首先要找出系统的执行者。可以通过用户回答一些问题的答案来识别执行者。以下问题可供参考： 
      </dd>
      <dd>&middot;谁使用系统的主要功能（主要使用者）。 </dd>
      <dd>&middot;谁需要系统支持他们的日常工作。 </dd>
      <dd>&middot;谁来维护、管理使系统正常工作（辅助使用者）。 </dd>
      <dd>&middot;系统需要操纵哪些硬件。 </dd>
      <dd>&middot;系统需要与哪些其它系统交互，包含其它计算机系统和其它应用程序。 
      </dd>
      <dd>&middot;对系统产生的结果感兴趣的人或事物。 </dd>
      <dd>　</dd>
      <dd>b. 获取用例 </dd>
      <dd>一旦获取了执行者，就可以对每个执行者提出问题以获取用例。以下问题可供参考： 
      </dd>
      <dd>&middot;执行者要求系统提供哪些功能（执行者需要做什么）？ </dd>
      <dd>&middot;执行者需要读、产生、删除、修改或存储的信息有哪些类型。 
      </dd>
      <dd>&middot;必须提醒执行者的系统事件有哪些？或者执行者必须提醒系统的事件有哪些？怎样把这些事件表示成用例中的功能？ 
      </dd>
      <dd>&middot;为了完整地描述用例，还需要知道执行者的某些典型功能能否被系统自动实现？ 
      </dd>
      <dd>还有一些不针对具体执行者问题（即针对整个系统的问题）： </dd>
      <dd>&middot;系统需要何种输入输出？输入从何处来？输出到何处？ </dd>
      <dd>&middot;当前运行系统（也许是一些手工操作而不是计算机系统）的主要问题？ 
      </dd>
      <dd>　</dd>
      <dd>&nbsp;&nbsp;&nbsp; 
        需要注意，最后两个问题并不是指没有执行者也可以有用例，只是获取用例时尚不知道执行者是什么。一个用例必须至少与一个执行者关联。还需要注意：不同的设计者对用例的利用程度也不同。例如，Ivar 
        Jacobson说，对一个十人年的项目，他需要二十个用例。而在一个相同规模的项目中，Martin 
        Fowler则用了一百多个用例。我们认为：任何合适的用例都可使用，确定用例的过程是对获取的用例进行提炼和归纳的过程，对一个十人年的项目来说，二十个用例似乎太少，一百多个用例则嫌太多，需要保持二者间的相对均衡。 
      </dd>
      <dt>　</dt>
      <dd><font size="3">1.用例图 </font><p>2.类图、对象图和包 
        数千年以前，人类就已经开始采用分类的方法有效地简化复杂问题，帮助人们了解客观世界。在面向对象建模技术中，我们使用同样的方法将客观世界的实体映射为对象，并归纳成一个个类。类（Class）、对象（Object）</p>
        <p>&nbsp;&nbsp;&nbsp; 
        和它们之间的关联是面向对象技术中最基本的元素。对于一个想要描述的系统，其类模型和对象模型揭示了系统的结构。在UML中，类和对象模型分别由类图和对象图表示。类图技术是OO方法的核心。 
        </p>
      </dd>
      <dd>(1) 类图 类图(Class Diagram)描述类和类之间的静态关系。与数据模型不同，它不仅显示了信息的结构，同时还描述了系统的行为。类图是定义其它图的基础。在类图的基础上，状态图、合作图等进一步描述了系统其他方面的特性。 
        (2) 类和对象 对象(Object)与我们对客观世界的理解相关。我们通常用对象描述客观世界中某个具体的实体。所谓类(Class)是对一类具有相同特征的对象的描述。而对象是类的实例（Instance）。建立类模型时，我们应尽量与应用领域的概念保持一致，以使模型更符合客观事实，易修改、易理解和易交流。 
        类描述一类对象的属性（Attribute）和行为（Behavior）。在UML中，类的可视化表示为一个划分成三个格子的长方形（下面两个格子可省略）。图1中，“客户”就是一个典型的类。 
        类的获取和命名 
        最顶部的格子包含类的名字。类的命名应尽量用应用领域中的术语，应明确、无歧义，以利于开发人员与用户之间的相互理解和交流。类的获取是一个依赖于人的创造力的过程，必须与领域专家合作，对研究领域仔细地分析，抽象出领域中的概念，定义其含义及相互关系，分析出系统类，并用领域中的术语为类命名。一般而言，类的名字是名词。 
        类的属性 
        中间的格子包含类的属性，用以描述该类对象的共同特点。该项可省略。图1中“客户”类有“客户名”、“地址”等特性。属性的选取应考虑以下因素： 
        *原则上来说，类的属性应能描述并区分每个特定的对象； *只有系统感兴趣的特征才包含在类的属性中； 
        *系统建模的目的也会影响到属性的选取。</dd>
      <dd>　</dd>
      <dd>&nbsp;&nbsp;&nbsp; 
        根据图的详细程度，每条属性可以包括属性的可见性、属性名称、类型、缺省值和约束特性。UML规定类的属性的语法为： 
        可见性 属性名 ： 类型 = 缺省值 {约束特性} 图1“客户”类中，“客户名”属性描述为“－ 
        客户名 : 字符串 = 缺省客户名”。 
        可见性“－”表示它是私有数据成员，其属性名为“客户名”，类型为“字符串”类型，缺省值为“缺省客户名”，此处没有约束特性。 
        不同属性具有不同可见性。常用的可见性有Public、Private和Protected三种，在UML中分别表示为“＋”、“－”和“＃”。 
        类型表示该属性的种类。它可以是基本数据类型，例如整数、实数、布尔型等，也可以是用户自定义的类型。一般它由所涉及的程序设计语言确定。 
        约束特性则是用户对该属性性质一个约束的说明。例如“{只读}”说明该属性是只读属性。 
        类的操作(Operation) 
        该项可省略。操作用于修改、检索类的属性或执行某些动作。操作通常也被称为功能，但是它们被约束在类的内部，只能作用到该类的对象上。操作名、返回类型和参数表组成操作界面。UML规定操作的语法为： 
        可见性 操作名 （参数表） ： 返回类型 {约束特性} 在图1中，“客户”类中有“取客户地址”操作，其中“ 
        ＋”表示该操作是公有操作，调用时需要参数“客户名”，参数类型为字符串，返回类型也为字符串。 
        类图描述了类和类之间的静态关系。定义了类之后，就可以定义类之间的各种关系了。 
      </dd>
      <dd>　<p>(3) 关联关系 关联（Association）表示两个类之间存在某种语义上的联系。例如，一个人为一家公司工作，一家公司有许多办公室。我们就认为人和公司、公司和办公室之间存在某种语义上的联系。在分析设计的类图模型中，则在对应人类和公司类、公司类和办公室类之间建立关联关系。 
        在图1中最上部存在一个“属于”/“签定”关联：每个“保险单”属于一个“客户”，而“客户”可以签定多个“保险单”。除了这个关联外，图1中还有另外两个关联，分别表示每个“保险单”包含若干个“保险单上的项目”，而每个“保险单上的项目”涉及单一的“保险类别”。 
        关联的方向 
        关联可以有方向，表示该关联单方向被使用。关联上加上箭头表示方向，在UML中称为导航（Navigability）。我们将只在一个方向上存在导航表示的关联，称作单向关联 
        ( Uni