<六>面向对象分析之UML核心元素之业务实体

一:基本概念

          ---->业务实体类(class)的一种版型。特别用于在业务建模阶段建立领域模型。业务实体是业务模型中非常重要的一个因素,它为问题领域中的关键概念建立概念化的理解。是人们认识问题领域的重要手段。如果说参与者和用例描述了我们在这个问题领域中达到的什么样的目标,那么业务实体就描述了我们使用什么来达到业务目标以及通过什么记录这个业务目标。
        ---->官方定义:业务实体代表业务角色执行业务用例处理或使用的“事物”。
        ---->一个业务实体经常代表某个对多个业务用例或用例实例有价值的事物,一般而言,一个好的业务实体不包含关于使用主体和使用方法的信息。
        ---->如何理解上述定义呢?
                (1)业务实体来自现实世界,在我们建模的问题领域里一定能够找到与它相对应的事物,并且这个事物是参与者在完成其业务目标的过程中使用的或创建出来的。并不一定对应一个具体的事物,dto是作为数据工具。
                (2)业务实体一定是在分析业务流程的过程当中发现的,而业务流程实际上就是业务的用例场景。这意味着业务实体必须至少被一个业务用例场景使用或创建,对业务用例场景没有贡献的事物,即使它客观存在,也不应该为它建模。例如,买衣服的场景中,挂衣服的衣架就是无贡献的。
                (3)业务实体作为类的一个版型,具有对象所有性质,包括属性和方法,同时具有对象的独立性,即业务实体只应当包含它本身固有的特性,而不能够包含外界是如何使用它的信息。例如:一把刀,就是一把刀,具有自身固有的属性和行为。这个业务实体我们之描述它的大小,材料,外观,锋利程度等,不能描述它是用来切菜的。因为它是不是用来切菜,得取决于业务场景。在厨师的厨房做菜的场景,就是切菜。在坏人则是用来抢劫的凶器。

二:业务实体的属性
        ---->属性是用来保存业务实体特征的记录,业务实体的属性集合决定了它的唯一性。
        ---->属性可以很容易从它所对应的现实事物中找到。例如,钱币,我们可以很容易找到它的属性:面额,材料,大小,防伪标识。但,在建模时,我们不需要把它所有的属性都列举出来,只在场景中有用的列举出来。
        ---->一般来说,如果只有一个对象可以直接使用这个属性,或者只能通过这个对象才能访问到这个属性,它就应当作为一个属性存在。否则就应当把它单独建模成一个业务实体。

三:业务实体的方法
        ---->方法是访问一个业务实体的句柄,它规定了外部可以怎样使用它。
        ---->方法是外部能够使用这个业务实体的全部信息。
        ---->不需要将这个业务实体所有可能的方法都列举出来,只列举场景中应用到的。
        ---->业务实体的方法也同样是面向对象方法中的抽象视角的体现。

四:获取业务实体
       -----> 在业务实体的定义里讲到:业务实体代表业务角色执行业务用例时所处理或使用的“事物”。一个业务实体经常代表某个对业务用例或用例实例有价值的事物。实际上这个定义就是我们获取业务实体的方法。
       ----->(1)建立业务用例场景。(2)从业务用例场景中诸葛分析动词后面的名词,他们就是业务实体的备选对象。(3)根据备选对象对业务目标是否有贡献这一筛选条件从备选列表中挑选出符合的对象。例如邮局是一个场所,它是寄信的一个约束,或者说前置条件,对寄信业务目标来说没有直接的贡献,应当把它从列表去掉。剩下的就成为初始的业务实体。(4)分析业务实体之间的关系,并决定哪些应当单独建模,哪些应当作为属性。比如地址和邮票都在信封上,其中地址只有信封能够承载,并且也只有通过信封来读取地址,所以地址应当作为信封的一个属性。而邮票虽然也在信封上,但是寄信人可以对邮票进行单独处理,比如在购买邮票时没有贴在信封上,所以邮票应该单独建模。

时间: 2024-07-31 19:38:00

<六>面向对象分析之UML核心元素之业务实体的相关文章

&lt;十&gt;面向对象分析之UML核心元素之关系

关系        --->在UML中关系是非常重要的语义,它抽象出对象之间的联系,让对象构成特定的结构.        一,关联关系(association)         --->关联关系是用一条直线表示的.        --->描述不同类的对象之间的结构关系.它在一段时间内将多个类的实例链接在一起,这与依赖关系是不同的.依赖关系通常表示两个实例之间的临时关联关系.        --->单行关联关系,A知道B的存在,B不知道A的存在.比如UML建模中,参与者知道用例的存在

&lt;七&gt;面向对象分析之UML核心元素之包

一:基本概念         ---->包是一种容器,如同文件夹一样.它将某些信息分类.形成逻辑单元        ---->包是UML非常常用的一个元素,它最主要的作用就是容纳并为其他元素分类.包可以容纳任何UML元素,例如用例,业务实体,类图等,也包括子包.        ----->UML认为好的分包具有高内聚,低耦合的性质.        ----->分包好坏手有包之间的依赖关系来评判的.事实上在UML里,包之间的关系定义也只有依赖关系.        ----->什

&lt;四&gt;面向对象分析之UML核心元素之用例

一:基本概念        --->用例定义了一组用例实例,其中每个实例都是系统所执行一系列操作,这些操作生成特定主角可以观测的值.        --->所谓用例,就是一件事情,要完成这件事情,需要一系列活动,而做一件事情可以有很多不同的办法和步骤,也可能遇到各种各样意外情况.因此这件事情是由很多不同情况的集合构成的.在UML中称之为用例场景.一个场景就是一个用例的实例.               --->一个系统的功能性是由一些对系统有愿望的参与者要做的一些事情构成的,事情完成后就

&lt;五&gt;面向对象分析之UML核心元素之边界

一:基本概念        ---->边界在UML图符里的定义只是一个简单的矩形,四个边决定了边界的内外.参与者,用例和边界相生相克.        ---->边界是一个很重要的概念,和封装的概念师出同门.面向对象,任何一个对象都有一个边界.        --->在收集需求时,我们总要先假定一个范围边界.在这个边界内寻找需求,而找到的需求集合又决定了最终边界的大小.在需求出来之前,我们必须先设想一个边界,这个边界的大小是不确定的,随着需求的明确,边界也逐步变得明朗.但是问题出在确定需求

&lt;三&gt;面向对象分析之UML核心元素之参与者

一:版型        --->在UML里有一个概念叫版型.有些书里也称类型,构造型.        --->这个概念是对一个UML元素基础定义的扩展.在同一个元素基础定义的基础上赋予特别的含义,使得这个元素适用于特定的场合.        --->例如(1)用例:的版型有:"业务用例","业务用例实现"                      (2)类:的版型有:"接口","边界类","实体类&

&lt;十二&gt;面向对象分析之UML核心元素之节点和设备

节点,设备 一:概念        ---->是带有至少一个处理器,内存以及可能还带有其他设备的处理元素.在实际工作中,一般说来服务器,工作站或者客户机都可以称为一个节点.        ---->节点就是应用程序的部署单元.        ---->节点元素特别用于部署图,描述应用程序在物理结构上是如何部署在应用环境中的,是一种包括软,硬件环境在内的拓扑结构描述.        --->在笔者看来,UML中定义的节点所能表达的信息并不够充分,对于应用环境的拓扑结构来说仅仅描述节点

&lt;十一&gt;面向对象分析之UML核心元素之组件

组件一:概念        --->组件是系统中实际存在的可更换部分,它实现特定的功能,符合一套接口标准并实现一组接口.        --->组件代表系统中的一部分物理实施.包括软件代码(源代码,二进制代码或可执行代码)或其等价物(如脚本或命令文件)        --->在UML的定义中,组件之间唯一的关系就是依赖.在Rose中,组件视图中允许的唯一链接也是依赖关系,而依赖意味着一个组件的修改会导致依赖于它的其他组件的修改.        --->在笔者看来,一个组件应当是一个

《面向对象分析与设计》一1.6关于统一建模语言UML

1.6关于统一建模语言UML UML最初是在多种面向对象分析与设计方法相互融合的基础上形成的,后来发展成为也可以用于业务建模以及其他非软件系统建模的语言.它于1997年11月被对象管理组织(Object Management Group)采纳为建模语言规范,随后被产业界和学术界广泛接受. UML定义了建立系统模型所需要的概念并给出了表示法,但它并不涉及如何进行系统建模.因此它只是一种建模语言,而不是一种建模方法.UML是独立于开发过程的,也就是说它可以适用于不同的开发过程. UML 2.4规范由

UML面向对象分析与建模-【3】用例图

  一.用例图的描述 用例(Use Case)是指系统的外部事物(活动者.设备或外部系统)与系统交互,它表达了系统的功能,即系统所提供的服务. 用例图是一种描述用例的可视化工具,用简单的图形元素表示出系统的活动者.用例及它们之间的关系,准确地表达了活动者与系统的交互情况和系统所能提供的服务.用例图是从用户角度而不是从开发者角度来描述对软件产品的需求,分析产品所需的功能和动态行为. 二.活动者 确定活动者.活动者可以通过泛化关系定义. 1.       系统的主要客户是谁 2.       谁从该