UML--核心元素之业务实体】的更多相关文章

1.0.0 Summary Tittle:[UML]NO.54.EBook.6.UML.2.002-[Thinking In UML 大象 第二版]- UML 核心元素 Style:DesignPattern Series:DesignPattern Since:2017-11-13 End:.... Total Hours:... Degree Of Diffculty:2 Degree Of Mastery:2 Practical Level:2 Desired Goal:2 Archiev…
关系        --->在UML中关系是非常重要的语义,它抽象出对象之间的联系,让对象构成特定的结构.        一,关联关系(association)…
一:基本概念        ---->在那大数项目中,分析类是被忽视的一种非常有用的元素.        ---->分析类用于获取系统中主要的“职责簇”,他们代表系统的原型类,是系统必须处理的主要抽象概念的“第一个关口”.如果期望获得系统的“高级”概念性简述,则可对分析类本身进行维护,分析类还可产生系统设计的主要抽象——系统的设计类和子系统.二:分析类的性质        ----->分析类代表系中主要的“职责簇”,这以为着分析类是从功能性需求向计算机实现转化过程中的“第一个关口”   …
包是一种容器,如同文件夹一样,将某些信息分类,形成逻辑单元.包可以容纳任何UML元素,例如用例.业务实体.类图等,也包括子包. 一.分包原则: (1)高内聚:被分入同一个包的元素相互联系紧密,伸至不可分割.同时这些元素具有某些相同的性质,使得包可以抽象出一些接口来代表包事物与包外进行交互. (2)低耦合:包的最理想状态是修改A.B.C任意一个包的元素,其他的任何一个包中的内容不受影响,即ABC之间无依赖关系或松耦合. (3)依赖关系不传递:如果实际情况难以做到完全解除依赖关系,那么至少应该保证包…
1.参与者 定义:在系统之外与系统交互的某人或某物. 特点:1.可以非人:2.与系统直接交互:3.主动发出动作并获得反馈:4.涉众(stakerholder)的代表 具有两个版型: 1.业务主角(business actor): 在需求阶段中用于业务建模 特点:针对业务人员而非计算机用户 2.业务工人(business worker) 特点:在业务过程中,扮演某一环节不可或缺的部分,但是该业务并非其主动提出,并获得最后的反馈: 2.用例 定义:定义了一组用例实例,其中每个实例都是系统所执行的一些…
如果说参与者和用例描述了我们在这个问题领域中达到什么样的目标,那么业务实体就描述了我们使用什么来达到业务目标以及通过什么来记录这个业务目标. 如果把问题领域比喻成一幢大楼的话,业务实体就是构成这幢大楼的砖瓦和石头. 业务实体包含属性和方法 属性是用来保存业务实体特征的一个记录.一个事物通常有非常多的属性,在建模的时候,我们是否要把它所有的属性都列出来呢?不需要. 我们只需要关心它与这个场景直接关联的那些属性. 方法是访问一个业务实体的句柄,它规定了外部可以怎样来使用它.比如一台电视,它的方法就是…
一:版型        --->在UML里有一个概念叫版型.有些书里也称类型,构造型.        --->这个概念是对一个UML元素基础定义的扩展.在同一个元素基础定义的基础上赋予特别的含义,使得这个元素适用于特定的场合.        --->例如(1)用例:的版型有:“业务用例”,“业务用例实现”                      (2)类:的版型有:“接口”,“边界类”,“实体类”,“控制类”        --->除了UML已经定义的版型外,为了在某种场合下让元…
定义:参与者是在系统之外与系统交互的某人或某事物.参与者在建模过程中处于核心地位. 1.系统之外:系统之外的定义说明在参与者和系统之间存在明确的边界,参与者只能存在于边界之外,边界之内的所有人和事务都不是参与者. 2.参与者可以非人:不存在没有参与者的用例,用例不应该自动启动,也不应该主动启动另一个用例.没有人参与的需求一定有别的事务在发出启动操作,这个事务就是参与者,可能是另一个计算机系统.一个计时器.一个传感器等. 3.特点:参与者对系统有着明确的目标和要求并且主动发出动作: 系统是为参与者…
一:基本概念        --->用例定义了一组用例实例,其中每个实例都是系统所执行一系列操作,这些操作生成特定主角可以观测的值.        --->所谓用例,就是一件事情,要完成这件事情,需要一系列活动,而做一件事情可以有很多不同的办法和步骤,也可能遇到各种各样意外情况.因此这件事情是由很多不同情况的集合构成的.在UML中称之为用例场景.一个场景就是一个用例的实例.       …
定义:边界是无形的,是可大可小的,同时参与者.用例和边界又有着相生相克的性质.与其说边界是UML元素,还不如说它是一种分析方法. 1.需求是动态的过程:系统边界是无形的,看不到的,不好理解,倒不如说需求的集合来的准确.但是不能先有需求再反过来推定边界,需求总是晚于系统边界出现的. 然而,需求是靠参与者和用例确定的,但是参与者和用例得以明确的前提条件又是边界确定:需求就是在不断调整这个矛盾的过程中逐步明确进而更加确定边界的.这个过程不可避免的会导致参与者和用例的变化,所以需求是一个动态的过程,统一…
分析类共有三个:边界类(boundary).控制类(control)和实体类(entity),这些分析类都是类的版型.分析类是跨越需求到设计实现的桥梁. 边界类:从需求向现实的转换过程中,任何两个有交互的关键对象之间都应该考虑建立边界类. 对现实世界来说,边界类的实例可以是窗口.通信协议.打印机接口.传感器.终端等. 在计算机世界里,当我们打算对A对象和B对象之间的交互进行建模时,边界类可以充当这一载体. 控制类:用于对一个或几个用例所特有的控制行为进行建模.控制对象通常控制其他对象,因此他们的…
定义:用例定义了一组用例实例,其中每个实例都是系统所执行的一些列操作,这些操作生成特定主角可以观测的值.一个完整的用例定义由参与者.前置条件.场景.后置条件构成. 1.理解用例:用例就是参与者希望通过系统达到的愿望.一个系统的功能性是由一些对系统有愿望的参与者要做的一些事构成的,事情完成后就达成了参与者的一个愿望,当全部参与者的所有愿望都能够通过用例来达到,那么这个系统就被确定下来了.捕捉功能性需求就是用例的作用. 2.特征: (1)用例是相对独立的: (2)用例的执行结果对参与者来说是可观测的…
一:动态视图 --->动态视图是描述事物动态行为的. --->需要注意的是:动态视图不能够独立存在,它必需特指一个静态视图活uml元素,说明在静态视图规定的事物结构下它们的动态行为. --->动态视图:活动图,状态图,时序图,协作图   二:活动图 --->活动图描述了为了完成某一个目标需要做的活动以及这些活动的执行顺序. --->uml中有两个层面的活动图,一种用于描述用例场景,叫[用例活动图],另一种用于描述对象交互,叫[对象活动图]. --->在面向对象的眼中是没…
一:状态图 --->状态图显示一个状态机. --->状态机用于对模型元素的动态性进行建模.更具体地说,就是对系统行为中受事件驱动的方面进行建模. --->通常使用状态图来说明业务角色或业务实体可能的状态----导致状态转换的事件和状态转换引起的操作 --->状态机主要用于描述对象的状态变化以确定何种行为改变了对象的状态,以及对象状态变化对系统的影响. (1)初始状态:初始状态是状态机的其实位置,他不需要事件的触发. (2)状态:状态是对象执行某项活动或等待某个事件时的条件. (3)…
一 HTML核心元素 1.文本标题 <h1>一级标题</h1> <h2>二级标题</h2> <h3>三级标题</h3> ... <h6>六级标题</h6> 2.段落 <p>段落文本内容</p> 3.空格 &nbsp: 4.加粗 <b>加粗文本</b> <strong></strong> 5.强制换行 <br /> 6.倾…
认识Fluent Vaidation. 看到NopCommerce项目中用到这个组建是如此的简单,将数据验证从业务实体类中分离出来,真是一个天才的想法,后来才知道这个东西是一个开源的轻量级验证组建. Fluent Validation 翻译为:流畅验证 开源Codeplex其主页简介:该组件是一个轻量级的.NET类库,使用流畅的接口定义和lambda表达式为构建一个业务类的验证规则(A small validation library for .NET that uses a fluent in…
应用场景:如何把数据库表中的一行转换成一个业务实体结构体,c#和java中都有实体框架,表到实体的转换很方便,c++中缺少这些框架,但是有一些折中的办法去做.其实问题的本质是:map如何转成结构体. 问题:map的字段和结构体字段一一对应时,如何把map中字段对应的值付给结构体中相同名称字段? 有点麻烦的地方:如何让结构体去在map中查找相应的字段值,一种办法是通过手写的办法,把每个字段名称写成常量字符串,然后去map中查找,找到后,再给该字段赋值,这个办法是可以的,但是重复性的硬编码了很多字段…
一:协作图 --->描述了对象间交互的一种模式.它通过对象之间的连接和它们相互发送的消息来显示参与交互的对象 --->协作图可以有对象和主角实例,以及描述它们之间关系和交互的连接和消息.通过说明对象间如何通过相互发送消息来实现通信,协作图描述了参与对象中发生的情况.可以为用例事件流的每一个变化形式制作一个协作图. --->与时许图相似,协作图用于显示对象之间如何进行交互以及执行特定用例或用例中特定部分的行为.     二:业务模型协作图 --->业务模型协作图同样采用业务实体来绘制…
一:时序图 --->时序图是用于描述按时间顺序排列的对象之间的交互模式. --->它按照参与交互的对象所具有的“生命线”和他们相互发送的消息来显示这些对象. --->时序图包含对象和主角实例,以及说明他们如何交互的消息. --->时序图描述了在参与交互的对象中所发生的事件(从激活的角度来说明),以及这些对象如何通过相互发送消息进行通信. --->时序图与协作图是可以相互转换的,与协作图不同的是,时序图强调消息事件发生的顺序,更方便于阐述时间流的过程.但是时序图很难表达对象之间…
UGUI的核心元素: Anchor(锚点):每个控件都有一个Anchor属性,控件的4个顶点,分别与Anchor的4个点保持不变的距离,不受屏幕分辨率变化的影响. 系统默认设置控件的Anchor位置在其父物体的中心处,且不能离开父物体的范围. 将Anchor设置在父物体的左侧,可以实现左对齐的效果. 将Anchor设置在父物体的4个顶点上,子物体将随父物体同步缩放. Pivot(轴):控件的中心点(或称为轴),控件围绕Pivot发生旋转(若想控件围绕某个顶点旋转,改变Pivot位置即可) Rec…
一:uml的核心视图 --->如果说UML是一门语言,上一章学习的参与者等元素是uml的基本词汇,那么视图就是语法.uml通过视图将基元素组织在一起,形成有意义的句子. --->uml可视化的特性是由各种视图来展现的,每一种视图都从不同的角度对同一个软件产品的方方面面进行展示.说明要开发的软件到底是一个什么样子. --->静态视图:一方面我们需要描述系统的结构性特征,结构决定这个系统能做什么.结构特性用静态视图来表达. --->动态视图:另一方面我们需要描述系统的运行时行为,这些行…
一:类图(行为类和实体类) --->类图用于展示系统中的类及其相互之间的关系 --->概念层类图 --->说明层类图   二:概念层类图 --->概念层的观点认为:在这个层次的类图描述的是现实世界中问题领域的概念理解. --->在概念层上,类图着重于对问题领域的概念化理解,而不是实现,因此类名称通常都是问题领域中实际事物的名称.就是处于概念阶段. --->比如:网上购物主要由商品,订单,支付卡这几个类构成.   三:说明层类图 --->说明层类图是搭建在现实世界和…
类图的作用:用于展示系统中的类及其相互之间的关系. UML在解决面向对象的方法中对类理解为三个层次,各自是:概念层.说明层.实现层.在UML中,从開始的需求到终于设计类,类图也是环绕这三个层次的观点进行建模的. 一.概念层类图 在概念层上类图着重于对问题领域的概念化理解.而不是实现,因此类名称通常都是问题领域中实际事物的名称. 网上购物主要由商品.订单.支付卡这几个关键类构成,这几个类的交互能够完毕网上购物这个业务目标. 二.说明层类图 这一层是类的接口而不是实现.类图中表达类和类之间的交互接口…
在UML中活动图的本质就是流程图,它描述了为了完成某一个目标需要做的活动以及这些互动的执行顺序.UML中有两个层面的活动图,一种用于描述用例场景,另一种用于描述对象交互. 活动图只是我们用来描述业务目标的达成过程并借此来发现对象的工具,它不是我们的分析目标,也不是编程的依据. 建立活动图: 一个登录过程的活动图如下:…