网站流量大小对网站有什么影响把货卖到国外有哪些平台

网站流量大小对网站有什么影响,把货卖到国外有哪些平台,wordpress邮件找客户端,室内设计联盟官方网站入口UML用类图#xff08;class diagram#xff09;表示类、接口及其关联。类图用于静态对象建模。 一、概述 类图(class diagram)展现了一组对象、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图。包含主动类的类…UML用类图class diagram表示类、接口及其关联。类图用于静态对象建模。一、概述类图(class diagram)展现了一组对象、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图。包含主动类的类图给出了系统的静态进程视图。1.类图的内容类图中通常包含以下内容类接口协作依赖、泛化和关联关系类图中也可以包含注解和约束。类图还可以含有包或子系统二者都用于把模型元素聚集成更大的组块。画UML类图推荐在processon上画。2.类图的使用场景类图用于对系统的静态设计视图建模。这种视图主要支持系统的功能需求即系统要提供给最终用户的服务。当对系统的静态设计视图建模时通常以下述3种方式之一使用类图。(1)对系统的词汇建模。对系统的词汇建模涉及做出这样的决定哪些抽象是考虑中的系统的一部分哪些抽象处于系统边界之外。用类图详细描述这些抽象和它们的职责。(2)对简单的协作建模。协作是一些共同工作的类、接口和其他元素的群体该群体提供的一些合作行为强于所有这些元素的行为之和。例如当对分布式系统的事务语义建模时不能仅仅盯着一个单独的类来推断要发生什么而要有相互协作的一组类来实现这些语义。用类图对这组类以及它们之间的关系进行可视化和详述。(3)对逻辑数据库模式建模。将模式看作为数据库的概念设计的蓝图。在很多领域中要在关系数据库或面向对象数据库中存储永久信息可以用类图对这些数据库的模式建模。二、类图的使用一类的表示法类是对一组具有相同属性、操作、关系和语义的对象的描述。关系是类之间的、语义是蕴藏的因此对于一个类而言其关键的特性是属性成员变量和操作成员方法​。如图所示类是用一个矩形表示的它包含三个分栏每个分栏分别写入类的名称、类的属性和类的操作。1. 名称每个类都必须有一个有别于其他类的名称。名称name是一个文本串。根据需求建模的惯例类的名称应采用CamelCase格式具体来说就是写出英文单词的全称并且每个单词的首字母用大写表示而且将避免使用特殊符号。2.属性属性attribute是已被命名的类的特性它描述该类实例中包含的信息在面向对象编程中它一般实现为类的成员变量。例如在如图所示的Order类中就列出了orderDate下订单时间​、destArea送货区域​、price订单总价格​、paymentType支付类型4个属性它们是用来描述每个具体的订单对象的。而且根据需求建模的惯例属性的命名规范也是CamelCase格式不过为了表示区别通常属性名的第一个字母是小写的。在需求建模时应该大胆地用中文命名类和类的属性。3.操作操作operation是类所提供的服务它可以由类的任何对象请求以影响其行为。但这个信息在需求阶段是没有的因为行为需求并不会体现在类中。二类之间的关系类之间最常见的关系有三类关联、泛化、聚合/组合下面我们就逐一地来认识它们。1.关联关系关联Association表示两个类之间存在某种语义上的联系。例如一个人为一家公司工作一家公司有许多办公室。我们就认为人和公司、公司和办公室之间存在某种语义上的联系。关联关系提供了通信的路径它是所有关系中最通用、语义最弱的。在UML中使用一条实线来表示关联关系。2.泛化关系泛化关系描述了一般事物与该事物中的特殊种类之间的关系也就是父类与子类之间的关系。继承关系是泛化关系的反关系也就是说子类是从父类中继承的而父类则是子类的泛化。在UML模型中我们使用带空心箭头的实线表示箭头指向父类如图不管是称之为“泛化”还是“继承”​对于非技术背景的客户而言都是无法听懂的对于此类读者正确的说法是“……分为几类包括……”​或“……是……的一类”​。3.聚合与组合关系关联关系包括两种比较特殊的关系聚合和组合它们都是用来表示整体/部门关系的应读作“……整体类是由……部分类组成的”​表示方法如图所示。1聚合关系聚合Aggregation是一种特殊形式的关联。聚合表示类之间的关系是整体与部分的关系。聚合关系的含义是“聚”在一起的意义也就是表示“部分”可以独立于“整体”而存在。在UML模型中使用一个带空心菱形的实线表示空心菱形指向的是代表“整体”的类。2组合关系如果发现“部分”类的存在是完全依赖于“整体”类的那么就应该使用“组合”关系来描述。在UML模型中组合关系是使用带有实心菱形的实线表示实心菱形指向的是代表“整体”的类。那么到底聚合与组合的区别在什么地方呢许多书籍虽然举过很多例子但是都忽略了一点这种例子是必须依赖于“应用场景”的。也就是要根据应用场景来对部分类和整体类之间的关系进行判断。例如​“电脑”是一个整体类而“主板”​、​“CPU”…则是相对于它的部分类。那么它们之间应该是什么关系呢如果开发的是固定资产管理系统可能就是“组合”关系甚至只是“电脑”类的属性而如果对于在线DIY的系统那么显然应该采用“聚合”关系。所幸的事不管是聚合还是组合对于面向对象的编程实现而言并没有实质的区别因此我们并不需要一定在这个问题上深抓不放它只是起到一个模型更清晰化的作用因此在实践中也无须过于执着。三类图的阅读在UML模型中只需20%的建模元素就能应对80%的应用场景特别是对于需求建模而言更是如此。因此必须首先清晰地掌握每种图的20%部分为了避免大家受到干扰我们就先来看一个只包含基本建模元素的简单类图。在阅读这种简单的类图时重要在于把握三项内容类、关系、多重性这也就是类图中那个重要的20%​。其阅读的顺序应遵从以下原则先看清有哪些类然后看看类之间存在的关系并结合多重性来理解类图的结构特点以及各个属性和方法的含义。1.读出类在前面我们已经详细讲解了类的组成及相应的图形表示法。借助于这一基础知识就不难读懂在图中共有7个类订单、订单项、客户、收货人、送货单、供应商、产品并且在每一个类中都定义了若干属性。2.读清类之间的关系在阅读类图时有一个实用的技巧那就是从图中关系最复杂也就是线最密集的类开始阅读。很显然在这个例子中这个类就是“订单”​。然后我们逐一地分析该类与其他类之间的关系。订单项”和“订单”之间是组合关系根据箭头的方向可知“订单”是由“订单项”组成的。显然对于该应用系统而言​“订单项”是不会单独存在的因此它们之间是组合关系。“订单”和“客户”​、​“收货人”​、​“送货单”之间是关联关系。也就是说一个订单和客户、收货人、送货单是相关的。而关系复杂的第二个类就是“送货单”​和它相关的也有4个类​“订单”​、​“订单项”​、​“收货人”​、​“供应商”。也就是表示“送货单”是与“订单”相关的同时还关联到“订单项”​为什么呢大家可以先想想​另外它和“供应商”​、​“收货人”之间的关联关系是很显然的。分析完这两个类之后我们会发现图中几乎所有的关系都已经列明了只剩下一个“产品”类了它所关联的类是“供应商”和“订单项”​。显然“产品”是属于某个“供应商”的而“订单项”中必须指出是什么“产品”​。3.理解数量关系数量关系在类图中是以多重性Multiplicity的形式表示的它又称重数。其表示格式为“n…m”​其中整数n定义所连接的最少对象的数目而m则为最多对象数当不知道确切的最大数时最大数用*号表示在Rose中则用n来表示​。最常见的多重性有0…1、0…n、1、1…n、n。建立了这个概念之后我们现在再来看图结合多重性概念后类图的含义就更加清晰了。四类图中常用的辅助建模元素如图所示的类图中就拥有更多的辅助建模元素不难发现这个图要比前一个复杂多了因此如果添加的辅助建模元素不是必要的反而会导致类图的可读性大大下降。和前面的图相比除了引入了“个人客户”和“公司客户”两个类它们都是“客户”类的一种之外还增加了大量新东西这些东西能够帮助我们更好地描述类图。1.导航箭号大家不难发现在图中表示关联的直线多出了箭头。在UML中我们称这种带箭头的关联表示性为“导航navigability箭号”​。对于关联的两个类而言有时两个方向的强弱是不同的为了帮助读者更好地理解哪个方向更强更适合从哪个方向进行阅读时就可以使用导航箭号来表示。另外如果没有箭头则表示是双向关联也就是等价于两端都有箭头即互相可以进行导航。2.角色名称另外在图中我们还会发现在“供应商”到“送货单”之间多了一个“执行者”的标注而在“供应商”和“产品”之间​“客户”和“订单”之间也有类似的字符串。这些字符串我们称之为角色名称它表示“供应商”是“送货单”的执行者​“供应商”是“产品”的提供者。通过使用这些角色名称可以使得类之间的关联关系更加的清晰化。但用来表示“客户”是“订单”所有者的标注就有“画蛇添足”之嫌。另外在UML中还可以对关联进行命名如图所示用虚线椭圆圈起来的部分​。一般来说关联名称应为动词短语表示该关联的语义角色名称是名词短语表示由关联实例链接的对象所扮演的角色。3.导出属性细心的读者可能会看到在“订单”类中有一个名为“价格”的属性它的前面加上了一个“/”符号。这在UML模型中是用来表示“导出derived属性”的。导出属性是指可以根据其他值计算出来的特性。为了说明“订单”类中的这个导出属性是如何计算出来的特意为其加了一个注释说明它是所有订单项中的价格总和。4.限定符在“订单”和“订单项”之间的组合关系中​“订单项”这端多了一个方框里面写着“产品号”​。它在UML中称为限定符存在限定符的关联称为受限关联它用来表示某种限定关系。在本例中它的用途是说明对于一张订单每一种产品只能用一个订单项。5.约束另外在图中我们还会发现在Order类的边上有一个用花括号括起来的文本里面写着“只有当所有的订单项都已经送到才能成功关闭订单”​。而在“个人客户”和“公司客户”类当中则有一根虚线上面写着“{xor}”​。在UML类图中这种以花括号括起来的、放在建模元素外边的字符串就是约束。约束可以用自由文本和OCL两种形式表示。在本例中前者是自由文本后者就是OCL中最基本的符号。在需求建模时应尽可能避免使用OCL这种复杂的表示法毕竟读懂它是很困难的况且对于用户而言更是如此。6.向非技术背景的用户解释通过以上的分析我们就能够正确地理解出这张类图所表示的信息那么当我们向非技术背景的用户解释这张类图时就不应该出现诸如聚合、泛化、关联之类的术语而是应该读作客户有两类个人客户和公司客户某个客户有且只能属于其中一类每个客户都会下多个订单每个订单中都有唯一的收货人每个订单是由多个订单项组成的组成一个订单的所有订单项的产品号是唯一的每个订单将被按产品的供应商拆分成多个送货单供应商是送货单的执行者每个订单项都将关联唯一的产品供应商是产品的提供者。五关联类除了上述的建模元素之外在类建模中还会用到一个很重要的概念那就是关联类。具体来说如果两个类之间具有多对多关系时那么就会发现有些属性是不容易放到任何一个类中的。例如在某个应用系统中有“人”和“协会”两个类显然每个“人”是可以属于多个“协会”的而每个“协会”则肯定会吸纳许多“人”​因此它们之间就是一个典型的多对多关系。这时如果要记录每“人”在某个“协会”中所担任的职务该存在哪呢这种属性是属于“人”还是“协会”呢很显然都不合适。这个信息是属于关联本身的特性因此我们可以通过关联类来对其建模如图所示。实际上关联类本身既是关联也是类它不仅像关联那样连接两个类而且还可以定义一组属于关系本身的特性。三、用UML类图进行领域建模的方法示例在进行领域建模时其工作主要就是“标识类、明确类之间的逻辑关系和数量关系、添加重要的结构规则”三个方面。下面我们就通过一个简单的实例来说明这个过程的具体操作方法。参考案例小王是一个爱书之人家里各类书籍已过千册而平时又时常有朋友外借因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号可以修改信息但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录可对外借情况列表打印。另外还希望能够对书籍的购买金额、册数按特定时间周期进行统计。1.标识类发现类的方法有很多种其中最广泛应用的莫过于“名词动词法”​下面我们就采用该方法开始问题域建模的第一步。而所谓的“名词动词法”​其主要规则是从名词与名词短语中提取对象与属性从动词与动词短语中提取操作与关联而所有格短语通常表明名词应该是属性而不是对象。1找到备选类首先我们可以逐字逐句地阅读上面那段需求描述并将其中的所有名词及名词短语列出来我们可以得到如下的备选类列表小王 人 家里 书籍 朋友 个人图书管理系统 基本信息书籍的 计算机类 非计算机 书名 作者 类别 出版社 关键字 功能 新书籍 系统 规则 书号 信息 记录 外借情况 外借情况列表 购买金额 册数 特定时限(2)决定候选类很显然并不是每一个备选类都是合适的候选类有些名词对于要开发的系统来说并无关紧要甚至是系统之外的而有些名词表述的概念则相对较小适合于某个候选类的属性。因此我们需要对备选类进行一番筛选将这些不合适的排除掉。“小王”​、​“人”​、​“家里”很明显是系统外的概念无须对其建模而“个人图书管理系统”​、​“系统”指的就是将要开发的系统即系统本身也无须对其进行建模很明显“书籍”是一个很重要的类而“书名”​、​“作者”​、​“类别”​、​“出版社”​、​“书号”则都是用来描述书籍的基本信息的因此应该作为“书籍”类的属性处理。而“规则”是指书号的生成规则书号则是书籍的一个属性因此“规则”可以作为编写“书籍”类构造函数的指南“基本信息”则是书名、作者、类别等描述书籍的基本信息统称​“关键字”则是代表其中之一因此无须对其建模“计算机类”​、​“非计算机类”是该系统中图书的两大分类因此应该对其建模并改名为“计算机类书籍”和“非计算机类书籍”​以减少歧义“外借情况”则是用来表示一次借阅行为应该成为一个候选类多个外借情况将组成“外借情况列表”​而外借情况中一个很重要的角色是“朋友”——借阅主体。虽然本系统中并不需要建立“朋友”的资料库但考虑到可能会需要列出某个朋友的借阅情况因此还是将其列为候选类。为了能够更好地表述将“外借情况”改名为“借阅记录”​而将“外借情况列表”改名为“借阅记录列表”​“购买金额”​、​“册数”都是统计的结果都是一个数字因此不用将其建模而“特定时限”则是统计的范围也无须将其建模。不过从这里的分析中我们可以发现在该需求描述中隐藏着一个名为“书籍列表”的关键类它也就是执行统计的主体。因为某个书可能是个系列有很多册。通过以上的分析我们就可以得到一个候选类列表书籍 计算机类书籍 非计算机类书籍 借阅记录 借阅记录列表 书籍列表要注意的是在使用“名词动词法”寻找类的时候很多团队会在此耗费大量的时间特别是对于中、大型项目这样很容易迷失方向。其实在此主要的目的是对问题领域建立概要的了解无须太过咬文嚼字。2.明确类间关系通过上面的工作我们从需求描述中找到了6个与问题域紧密相关的类接下来首要的任务就是理清类之间的逻辑关系。(1)确定关联关系很明显我们可以发现“计算机类书籍”​、​“非计算机类书籍”与“书籍”之间是继承关系也就是“书籍”分成了“计算机类书籍”和“非计算机类书籍” 两类​。而“书籍列表”则是由多个“书籍”组成的​“借阅记录列表”是由多条“借阅记录”组成的。这种组成关系适用于组合还是聚合关系呢显然由于在本系统中“书籍”是可以独立于“书籍列表”存在的​“借阅记录”也是可以独立于“借阅记录列表”而存在的因此使用聚合更合适一些。另外还可以发现“借阅记录”是与“书籍”关联的如果离开了“书籍”​​“借阅记录”将失去意义。为了反映和记录这些类之间的关联关系就可以使用UML中的类图将其记录下来。2多重性分析但是图中并无法将关联关系的细节信息传递出来。例如一本书可以有几条借阅记录这些问题需要进一步多重性分析并修改上面所列出的类图。系统应用于个人藏书管理因此每本书都是唯一的没有副本。因此其要么被借出去要么未被借出因此对于每一本书籍来说要么没有借阅记录要么也只有一条借阅记录。所有的书籍组成书籍列表借阅记录列表则也是由所有的借阅记录组成的而聚合、组合关系表示的就是整体/部分关系就是一种一对多的关系因此无须显式表示出来。通过上面的分析我们可以将得到的数量关系补充到类模型中。这样我们就对所有问题域中的各个类之间的结构关系、协作关系有了一个完整的了解与认识。而对于较大的系统而言还可以在此基础上对一些关联度大的部分类合成一个包以便更好地抽象系统。例如在本例中可以将“书籍列表”​、​“书籍”​、​“非计算机类书籍”​、​“计算机类书籍”合成一个包而将“借阅记录”与“借阅记录列表”合成一个包。不过本示例比较简单类也相对较少因此无须进行这样的抽象。3.确定类的主要职责当找到了反映问题域本质规则的主要类并理清它们之间的协作关系之后就可以为这些类添加其相应的职责。**什么是类的职责呢**它包括以下两个主要内容类所维护的知识类能够执行的行为。相信大家从上面的两句中马上会想到类的成员变量也称为属性和成员方法吧是的成员变量就是其所维护的知识成员方法就是其能够执行的行为。在本阶段我们就是根据需求描述的内容以及与客户简单沟通得到的信息描述出主要类及其主要成员变量以便更好地理解问题域。但对于成员方法而言则是应该属于行为需求的领域应该体现在用例模型中用户是难以理解某个东西具有什么操作的书籍类从需求描述中我们已经找到了描述书籍的几个关键成员变量即书名、类别、作者、出版社同时从统计的需要中我们可以得知“定价”也是一个关键的成员变量。借阅记录类而针对“借阅记录”这个类其关键的成员变量也一目了然即借阅人朋友​、借阅时间。通过上面的分析我们对这些概念类的了解更加深入可以重新修改类图将这些信息加入原先的模型得到如图所示的结果。要注意的是添加类的成员属性是一个循序渐进的过程在领域类分析、设计时都将逐步对类模型进行完善。另外值得说明的是由于这个例子比较简单因此我们在分析职责时主要是结合需求的文字表述来分析的。而在实际的应用中我们可以借助CRC卡等技术来辅助类职责的分析。4.补充类之间的结构规则到此为止我们得到了一张基本的类图其中只包含了类、类之间的关联性、多重性以及一些主要的属性和方法。接下来则将在图中的基础上添加一些高级特性以及限定。不过需要再次重申类图中的诸如导航性、角色名、导出属性、限定符及约束等修饰属性并不是每个类模型都必须加入的。例如本例中只要大家能够清晰地理解它所表示的含义就可以暂停了。但为了给读者提供一个范例下面就借助导航性、限定符及约束来细化类模型因为角色名称在本例中显然是无须指出的而本例中也不存在导出属性​。1导航性分析在图中只有“书籍”与“借阅记录”之间存在关联关系。而显然它们之间是一种双向关联当我们浏览书籍列表时会希望看到某本书是否已被借出而当有人归还书籍时我们又希望能够从借阅记录中关联到书籍。而在UML中不加导航箭头和在两端都加上导航箭头是一样的因此无须修改。2约束由于这个例子很简单因此没有太多需要添加约束的地方。根据用户需求我们有两个地方可以用约束来体现“书籍”对象创建后就不能够被删除只能被修改因此我们在Book类边上加上了一条用自由文本写的约束显然一本书要么属于计算机类要么属于非计算机类因此我们在两个“泛化”关系上增加一个“{二者取之一}” 的约束。如果用OCL语言进行标识那么可以使用符号“{Xor}”​说明它们中只能够选一个。四、用UML类图领域建模的常见误区1.立即给关联指定多重性确保每个关联都有明确的数量关系在进行领域建模时类之间的数量关系是十分重要的但却也不应该追求确保每个关联都有明确的数量关系因为有时这种数量关系并不是马上可以确定的。永远记住领域建模是对问题域的结构规则的忠实传递。特别是当建模出十分具体的数量关系时通常是一种十分危险的做法很可能会产生不良的后果。例如在图中明确地定义了客户拥有13种支付方式就是一种危险的做法。因为随着业务的发展企业支持的支付方式会随之增多这样就将导致系统无法有效地进行处理。2.对名词和动词做过度的分析而背离初衷正如前面所述名词动词法是在类建模时很有效的手段但是绝对不是让大家陷入到文山书海中去试图罗列出所有的名词这样很容易导致“分析崩溃”​。它只是一种手段我们在捕获、分析时可以借助这一思路帮助我们寻找到候选类。3.不对用例和时序图进行研究就将操作分配给类领域建模时是不考虑成员方法的这部分信息从属于“行为需求”​它应该是在流程图、用例描述中体现的。而根据这些行为需求来确定类的操作属于设计的范畴对于用户是不可见的。4.对象和类的通用程度越高在其他项目中重用它们的可能性就越大这个错误是很多需求分析员经常犯的错误总是试图在领域模型中对类进行抽象以便于在更多的项目中重用。但它会破坏对问题的理解甚至可能将这种抽象带到软件实现中从而导致向用户呈现了不好的用户界面。比如用户想导入一个报表结果信息管理系统中叫“模块导入”导致用户找不到可以导入的地方。5.对于每个“整体/部分”关系就使用聚合还是组合表示而争论不休正如前面所述聚合和组合都是整体/部分关系区别在于表示“部分”的类是否能够独立于“整体”而存在。实际上有些时候这种关系并不是那么显然的而此时通常也不是一个十分重要的问题因此只需简单地表示为聚合关系即可。而如果区分它们很重要的话也不应该由技术团队来争论而是应该从业务规则的角度来思考。6.未对问题空间进行建模之前就假定一种具体的实现策略当负责程序开发的团队来负责需求工作时这种情况就很常见总会思考这东西应该怎么实现。但却忘记了这些内容是用户无法感知、也不关心的。它应该在设计阶段进行考虑。7.将类命名为难以理解的名称而不是直观的名称很多团队抱怨说用户根本无法看得懂类图实际上一定要注意“看得懂”的真正含义其实关键在于是否理解它的含义。如果在类图中添加了许多实现细节摆上了一大堆英语表示的名称甚至是经过了技术加工后的产物时用户当然是无法很好地理解的。我们是要借助类模型来完成与用户的沟通因此应该采用用户熟悉的命名方法。8.直接进入到实现结构如友元关系和参数化类这个问题和第6个有相似之处只不过它更进了一步这些东西是属于详细设计的范畴用户当然是无法理解的。9.领域类和关系型数据库表之间建立一对一的映射领域建模的视图是“需求视图”​数据库表是“DBA视图”​它们的关注点是不同的领域建模是数据库表设计的基础但不应过早地进行映射。10.过早地执行“模式化”在需求阶段没“设计模式”什么事你需要做的仅仅是忠实地描述出问题域中各个业务实体之间的关系。11.过早地将子类合并掉例如有人看到如图所示的领域类模型片段时总会忍不住要合并它。他会想个人客户、公司客户只要在客户类中加一个“客户类型”字段就行了所以不必将其表示成类。但这样的做法对于领域建模而言是不正确的其中原因包括两个方面一是没有有效地将客户包括哪些类型传达给开发团队二是过早地决定可能会产生问题例如个人客户信息和公司客户信息很可能是不同的。12.过早对大类进行分拆和抽象例如将客户类分拆为客户基本信息、客户联系信息……。以及经常会对一些同类进行抽象比如将报表格式、表单格式抽象成为模板。这些做法都会阻碍与客户的交流与验证。上面罗列的所有这些原则看起来纷繁复杂、不好记住实际上可以总结成一句简单的话那就是领域模型的要点是拒绝实现、保持简单、忠于问题域。