uml

UML类图与类的关系详解

感情迁移 提交于 2020-01-17 08:03:03
虚线箭头指向依赖; 实线箭头指向关联; 虚线三角指向接口; 实线三角指向父类; 空心菱形能分离而独立存在,是聚合; 实心菱形精密关联不可分,是组合; 来源: CSDN 作者: shuzhou12 链接: https://blog.csdn.net/qq_34680763/article/details/103981316

敏捷日记

大兔子大兔子 提交于 2020-01-17 08:00:59
近来做了点东西有一点儿心德想要分享一下,也许在写的过程中有些描述的欠缺,但是也算是一点心德了,希望大家指正。 是否在项目中采用UML实际上一直是一种矛盾的事情,你说它有用吗,它真有用,你说它没有用吧,它真是一个废物。此话怎讲哪?UML对于需要求变更量不大的项目,那可是法宝一件,有种倚天即出,谁与争峰的感觉.但是如果项目中频频变更需求那么好吧乖乖,UML就是废物一个,成为项目组中人见人怕的怪物。 所以说我建议大家采用敏捷的方法开发,配合UML中常用的图例进行组员沟通与理解就不失为一种比较好的方法了,采用纯粹的敏捷开发一点儿文档也没有的话,我个人感觉前期开发人员会乐死,后期维护人员会哭死,特别是对于现今中国软件开发公司人员流动过快的现象,这种事真的是太多太多了。 做一个简单的比喻吧: 采用传统式流程式开发的兄弟们:好像是一群建筑设计院出来创业的老学究,事事讲究,什么都是理论一套一套的,一到实际盖房子的时候全部完蛋,为什么哪?主要是因为这帮学究们天天只会待在房子里研究,但是一盖房子全部都傻,没有实战过,对现场开发是一个白痴。但是奇了怪了就是这样的一帮人就能拿到大项目的单子,为什么哪?揪其根源主要在于人都是好面子的,一听你找了一个包工头子干这个项目,打死政府也不敢给你项目,所以一般都是白痴做一包,我们做二包,如果感觉不爽,你可以再找三包了。。。。 采用敏捷开发的兄弟们:这帮人一般都比较猛

use case diagram how do it better

此生再无相见时 提交于 2020-01-17 05:22:11
问题 hello, my first question is how I can place cases to better readability? I want to make this diagram fit on a A4-sized paper. But I am aware that this diagram may be badly made, so I ask you to advice, maybe I should share on the smaller part? 回答1: You need to to connect a use case only to its primary actor. So eventually you have to create a common role where the UC is used by this common actor role. Then your specific actors inherit from this common one. Like in @Amir's example

Limitations of Packaging Components in Sparx EA?

别来无恙 提交于 2020-01-17 01:18:12
问题 I'm running into what I would say are some limitations with the Packaging Components in Sparx EA. I use them to aggregate a number of commonly-themed web services in a Package. To be specific, they are JAX-RS Web Services. I model the Resource as a Packaging Component and the invokable method of the resource as Components. I created a profile and added stereotypes, etc. as per documentation. When I use them as an MDG Technology in my model, the stereotypes I created for Components were

Two (or more) aggregation relationships between two entities

橙三吉。 提交于 2020-01-16 18:10:50
问题 Consider the following (abstract) situation: Two entities. There are two aggregation relationships between the two entities. The diagram looks like this: I know this might sound vague, but is there anything wrong with this picture? I mean, are there any (obvious) problems that could arise from this kind of design? Or am I being paranoid and there's absolutely nothing wrong with two (or more) aggregation relationships between two entities? 回答1: For me there is nothing wrong in such design.

【UML建模】UML类图几种关系的总结

Deadly 提交于 2020-01-16 16:39:26
转自: http://kb.cnblogs.com/page/129490/ 在UML类图中,常见的有以下几种关系: 泛化(Generalization), 实现(Realization),关联(Association),聚合(Aggregation),组合(Composition),依赖(Dependency)    1. 泛化( Generalization )   【泛化关系】:是一种继承关系,表示一般与特殊的关系,它指定了子类如何特化父类的所有特征和行为。例如:老虎是动物的一种,即有老虎的特性也有动物的共性。   【箭头指向】:带三角箭头的实线,箭头指向父类   2. 实现( Realization )   【实现关系】:是一种类与接口的关系,表示类是接口所有特征和行为的实现.   【箭头指向】:带三角箭头的虚线,箭头指向接口   3. 关联( Association)   【关联关系】:是一种拥有的关系,它使一个类知道另一个类的属性和方法;如:老师与学生,丈夫与妻子关联可以是双向的,也可以是单向的。双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。   【代码体现】:成员变量   【箭头及指向】:带普通箭头的实心线,指向被拥有者   上图中,老师与学生是双向关联,老师有多名学生,学生也可能有多名老师。但学生与某课程间的关系为单向关联,一名学生可能要上多门课程

UML 类图笔记

倖福魔咒の 提交于 2020-01-16 16:38:47
在UML类图中,常见的有以下几种关系: 泛化(Generalization), 实现(Realization),关联(Association),聚合(Aggregation),组合(Composition),依赖(Dependency) 1. 泛化(Generalization) 【泛化关系】:是一种继承关系,表示一般与特殊的关系,它指定了子类如何特化父类的所有特征和行为。例如:老虎是动物的一种,即有老虎的特性也有动物的共性。 【箭头指向】:带三角箭头的实线,箭头指向父类 2. 实现(Realization) 【实现关系】:是一种类与接口的关系,表示类是接口所有特征和行为的实现. 【箭头指向】:带三角箭头的虚线,箭头指向接口 3. 关联(Association) 【关联关系】:是一种拥有的关系,它使一个类知道另一个类的属性和方法;如:老师与学生,丈夫与妻子关联可以是双向的,也可以是单向的。双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。 【代码体现】:成员变量 【箭头及指向】:带普通箭头的实心线,指向被拥有者 4. 聚合(Aggregation) 【聚合关系】:是整体与部分的关系,且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系,轮胎离开车仍然可以存在。 聚合关系是关联关系的一种,是强的关联关系;关联和聚合在语法上无法区分,必须考察具体的逻辑关系。 【代码体现

Entity Control Boundary (ECB) vs Model View Controller (MVC)

你。 提交于 2020-01-16 06:49:10
问题 I'm not sure if i got the right concept. I was told by people that Boundary = View Entity = Model Control = Controller however based on my knowledge of MVC. (fat model, thin controller) Isn't the Boundary = Controller, Control = Model (the busienss logic) and Entity = Model (The orm classes or similar entity classes which does only crud ). I may be wrong, please guide me! 回答1: Actually your first definition is simply correct. The meaning of words is sometimes confusing. The following link

Entity Control Boundary (ECB) vs Model View Controller (MVC)

早过忘川 提交于 2020-01-16 06:48:09
问题 I'm not sure if i got the right concept. I was told by people that Boundary = View Entity = Model Control = Controller however based on my knowledge of MVC. (fat model, thin controller) Isn't the Boundary = Controller, Control = Model (the busienss logic) and Entity = Model (The orm classes or similar entity classes which does only crud ). I may be wrong, please guide me! 回答1: Actually your first definition is simply correct. The meaning of words is sometimes confusing. The following link

can I connect the actor to a user case and its included use case?

青春壹個敷衍的年華 提交于 2020-01-16 06:04:51
问题 I have a use case that the actor will contact with, that use case includes two other use cases. The actor can contact with them as well. So my question can I connect the actors to those two use cases? This the first image where the actor is just connected to the main use case, this is the second image where the actor is connected to both the main use cases, and its included two use cases is the second correct? 回答1: If the included use case (UC) can be run only as inclusion/extension to some