UML建模
文章平均质量分 50
workflower
这个作者很懒,什么都没留下…
展开
-
UML中的条件,语义的完整性可以通过树判断
把约束集看成复合谓词的集合,这是最一般的情形.约束集的全域覆盖性通过复合谓词的个体域反映谓词的真值.约束集中的任意一个复合谓词condi都包含了多个受约束对象,使condi的真值取永真的个体域的组合形成了集合Di,所有的这种Di构成了约束集的全域。客户订单变更时,需要对订单的各种状态进行判断,包括订单的发货状态、生产状态、原材料供应商发货状态,并依据此进行生产变更、调整采购计划以及调整生产计划.因此,受约束对象以及原子谓词的形式如下。DLV1: 发货状态=已发货 DLV2: 发货状态=未发货。原创 2024-10-03 07:36:48 · 335 阅读 · 0 评论 -
UML建模案例分析-错误的状态图
在状态图中,把每时刻的系统状态抽象成状态和事件,然后组成一个网络,侧重于描述每一类对象的动态行为。它是对某一时刻中属性特征的概括,并且每种状态间存在着迁移,迁移则表示了这类对象在何时对系统内外发生的哪些事件作出何种响应。这里以借书的状态图为例,把上面的面向对象分析与设计、并对系统静态结构的把握后,建立起系统动态数据的逻辑视图.这种图,不是状态图,连最基本的形式都没有遵守。最起码,表示状态的词语,比如“正在...”,“结束”都不存在,每个状态都是以动词开头,妥妥的一个活动图。原创 2024-08-30 01:00:00 · 470 阅读 · 0 评论 -
UML建模案例分析-过细的用例图
UML的用例图较详细和确切地描述了用户的功能需求,使系统责任明确到位,奠定UML对系统建模的基础,这样,其他模型图的构造和发展依赖于用例图中所描述的内容,直至系统能够实现用例图中描述的功能。采用用例图描述的图书管理主要包括三类用户:读者、图书管理员、系统管理员。其中,读者是多个,图书管理员是几个,系统管理员是一个。对于系统,读者可以查询自己的借阅情况、分门别类的查询图书和在规定期限内续借不能超过一次操作的情况下进行自行登录续借书等。用例图里,如果用例较多,不重要的用例可以省略。原创 2024-08-30 01:00:00 · 381 阅读 · 0 评论 -
设计模式-标识映射(Identity Map)
标识映射记录在一个业务事务中从数据库读出的所有对象。无论什么时候要用一个对象,先检查标识映射,看需要的对象是否已经在内存中。标识映射最基本的思想是使用一系列映射,包含了从数据库读出的对象。由于需要与并发管理交互,还应该考虑使用乐观离线锁。通过在映射中保存每个已经加载的对象,确保每个对象只加载一次。当要访问对象的时候,通过映射来查找他们。从数据库加载对象时,对象与其映射的一致性、重复加载,这些都是需要得到保证的。原创 2024-08-12 12:12:06 · 652 阅读 · 0 评论 -
UML建模案例分析-活动图商业建模
活动图主要用来描述如何完成工作以及做什么工作。可以用活动图来描述操作、类或用例,但是它们只能显示工作流。可以用活动图来进行商业建模,在模型中,工作、工人、组织、对象被显示。原创 2024-08-11 01:00:00 · 469 阅读 · 0 评论 -
UML建模案例分析-状态图之间发消息
状态图间的消息发送可以通过动作(即,在发送子句中指定接收者)或在状态图间的虚线箭头来表示。如果使用虚线箭头来表示,则必须将状态图中的所有对象组合在一起(即使用类矩形符号)。可以采用两种不同的技术来画出表示状态图间的消息发送的虚线箭头。第一种方法是从源对象的状态转移画虚线箭头至目标对象的边缘(这种方法实际上是发送子句中的文本表示方法的另一种表示)。然后,在目标对象中画一条状态转移线,表示收到指定的消息。第二种方法是从源对象画虚线箭头到目标对象,表示在执行过程中的某- -时刻,源对象发送消息给目标对象。原创 2024-08-10 07:48:48 · 273 阅读 · 0 评论 -
UML建模案例分析-数字表状态图以及java实现
显示了该实体如何根据当前所处的状态对不同的事件做出反应。状态图(Statechart Diagram)是描述一个。下面是一个数字表的状态图。原创 2024-08-10 07:44:11 · 673 阅读 · 0 评论 -
UML建模-测试用例
在此期间,各种问题和想法还会产生,比如,修改用例的不足之处,或在用例中添加新功能。常用的测试方法有二种,一种是用具体的用例测试系统的行为,又称“漫游用例”;扮演角色的人首先说出角色应传给系统的消息,然后系统接收消息开始执行,在系统执行过程中,扮演系统的人说出他正在做的工作是什么。因此,可以让每个人分别多次扮演各个角色或系统,从而为建模者提供更多的信息,减少用例描述的遗漏和含糊不清。当所有的角色都被扮演,且所有的用例都以此方式执行过了,那么对用例模型的测试就算完成了。用例可用于测试系统的正确性和有效性。原创 2024-08-09 16:49:20 · 417 阅读 · 0 评论 -
《面向对象技术引论》题目-带答案
从系统的观点出发,我们可以给对象作如下定义:对象是系统中用来描述客观事物的一个实体,它是构成系统的一个基本单位(单元),一个对象是由一组属性和对这组属性进行操作的一组服务构成的。如果类A具有类B的全部属性和服务,而且具有自己特有的某些属性和服务,则类A叫做类B的特殊类,类B叫做的类A的一般类。限定词是关联的一个特定的属性(而不是工作台或工件的属性,其实该属性与工作台及工件都有关,是使二者发生关联的数据之一),它的值划分了通过一个关联与一个对象相关的对象集。接口是描述一个类或构件的一个服务的操作集。原创 2024-08-09 16:41:11 · 916 阅读 · 0 评论 -
UML建模案例分析-车险理赔
出险通知书、索赔报告、财产损失清单、接受书、权益转让书、赔款收据(该六项单证由保险公司提供格式,由被保险人填写并加盖公章);三、铁路货运的需铁路公安部门出具货运记录,航空货运的需出具航空事故签证,公路运输属货物被盗的同时报当地公安机关。八、本货物运输保险理赔指引适用于一切国内货物运输保险理赔(包括公路、铁路货运和航空货运)。被保险人向承运人(货运公司)的索赔函及承运人的答复资料;七、理算核赔部门完成理算、核赔工作并报送财务处理中心划款。整批货物的运单及货物发票(包含受损货物的单价明细);原创 2024-08-08 09:55:20 · 486 阅读 · 0 评论 -
UML建模案例分析-用例图中不存在的信息传递
用例图(Use Case Diagram)是用户与系统交互的最简表示形式,展现了用户和与TA相关的用例之间的关联关系。按照概念,用例图就是用户能做什么,至于用例之间的关系,只有三种:泛化、包含和扩展,多出一种都是错的。原创 2024-07-17 10:30:46 · 336 阅读 · 0 评论 -
UML建模案例分析-类图的改良
一般的思路,可能会设计成这样,似乎也无可非议。简单粗暴,各有各的属性。但有个最大的问题,就是产品分类不能再改变。如果某电子产品,为了提高销量,把它从电子产品类更改到电器类,属性也要修改。所以,如果发现类图中存在大量相似的类,那就需要改良了。上例中,可以考虑把共性的概念抽象成数据,产生一个“类别”类。合理的类图未必是最精良的,而这又对最终软件开发进度以及后续的维护影响极大。但是,商品的特征千差万别,这时可以考虑属性-属性值的方法。四个类就可以表示所有商品及其类别,并且以后可通过配置任意修改商品所属分类。原创 2024-07-14 07:38:17 · 404 阅读 · 0 评论 -
UML建模案例分析-需求对类图的影响很大
如果再仔细研究需求,企业产品的价格未必只有一个,如果系统中还有销售,价格会考虑出厂价、批发价、统一零售价等等;企业未来如果建立多个仓库,每个仓库的存量都需要管理的话,库存也不一定是唯一的。所以最后的类图很可能是这样的。概念是概念,但类图受需求的影响是非常大的,可以说类图是建模的源头。尽管用例图是源头,但对类图的作用有限。进销存系统里,产品类中,至少要包括如下属性:名称、规格、详细信息、价格、库存。乍一看,类图就是这样的,没什么争议。没有永远的类图,只有永远的需求。类图描述系统中类的静态结构。原创 2024-07-14 07:25:57 · 212 阅读 · 0 评论 -
UML建模案例分析-类图中的关系
以订单为例:订单和订单项之间是组合关系,这和数据库实体之间不一样。数据库实体有主外键,开发数据库时间久了再去建立类图,就总不放心两个类之间通过什么关联的,就总想着增加一个“外键”,比如在订单项类中增加一个属性“订单编号”,这回就放心了。另外强调一点,因为订单和订单项之间是组合关系,组合和聚合这种表示"强"拥有的关系,通常都是让订单项作为订单的属性;订单项和零件类之间也是如此,只是关联关系有方向,即,只能在订单项中创建零件的对象,反之不行。检查订单完整性();原创 2024-07-13 08:06:31 · 524 阅读 · 0 评论 -
UML建模案例分析-时序图和类图的消息传递
以检查库存为例,检查库存()消息应该发送给库存,对吧?这是因为类图中类的交互有一条路径:订单->订单项->零件->库存。也就是说,要检查的库存,是零件的库存,而零件又是指订单项里的零件,订单项又是订单的,所以消息传递要先传递给订单,再通过这个路径发送到库存。会员请求结账时,系统验证会员的账户是否处于登录状态;最后,系统合计订单总价(订单总价=所有订单项价钱合计+税金+运费);类图和时序图之间的交互是通过消息,即成员函数的调用体现的。看得出,用UML设计的人,必须是代码能力过硬才能设计的周全。原创 2024-07-10 09:16:59 · 635 阅读 · 0 评论 -
UML建模案例分析-时序图和类图的对应关系
会员请求结账时,系统验证会员的账户是否处于登录状态;系统验证订单是否完整以及各零件库存是否充足;最后,系统合计订单总价(订单总价=所有订单项价钱合计+税金+运费);一个电子商务系统,会员可通过电子商务系统购买零件。简单地说,类图定义了系统中的对象,时序图定义了对象之间的交互。原创 2024-07-10 08:52:25 · 526 阅读 · 0 评论 -
UML建模案例分析-用例图如何处理“登录“
要灵活处理体现关键核心的用例关系,忽略掉次要关系。原创 2024-07-08 09:16:11 · 495 阅读 · 0 评论 -
UML建模案例分析-会员下订单的时序图
但建模时,这个新增的订单检查消息建议省略。原因是:建模的目的是描述事物的主要特征,而不是全部内容,模型太繁琐失去可读性,也就失去了它用于沟通的属性。也称顺序图,捕捉一段时间范围内多个对象之间的交互信息,强调消息交互的时间顺序,将一个用例详细的记录出来。这一次交互从请求结账开始,用MVC架构的话,需要界面类和控制器类,但这两个类不是重点,重点是实体类之间的交互;系统没说什么时候下的订单,所以默认订单已经下完,不用再考虑下单的交互过程;{订单.检查订单完整性();订单.检查订单完整性();订单.检查库存();原创 2024-07-08 08:38:36 · 987 阅读 · 0 评论