uml

I'm trying to model some requirements and I saw some examples in the web with use cases generalization, but the UML 2.5 standard review doesn't say anything about generalization in Use Case Diagrams, or I can't find it. So, is generalization supported by standards? Since a UseCase is a Classifier, they can be generalized. The UML 2.5 spec contains an example of this in Fig. 18.11 on p. 686 (the "ATM Services" example). Tricky. While the Generalization relationship is defined as going between two Classifiers , and a Use Case is itself a specialization of a Classifier , the semantics of the

In UML, is it possible to draw an aggregation where the component object can access the composite object? Like in this image, but with only one association line, so the association end touching A would have a diamond and an arrow. If that isn't possible, the diagram I drawn is valid? If not, why? Another point of view, navigability is important to show how is it possible to navigate in the model and how to access to instances. Another point is about OCL, if navigability is not defined some OCL queries will be hard to write. Specification describes (p 198): Navigability means that instances

I would like to confirm whether I am on the right track when identifying common UML class relationships. For example, is the relationship between: 1 a stackoverflow member and his/her stackoverflow user account categorized as a composition relationship or an aggregation relationship? At first I thought it was an association because this member "has a" account. However on second thought, I am thinking its composition because each "part" (user account) belongs to only one whole (user) at a time, meaning for as long as I am logged into stackoverflow, I have to use this one and only account until

我常常陷入深思，我的女朋友为什么又生气了？是麻辣烫不好吃，还是韩剧不好看。直到有一天，她和我说，我知道你说xxx是为了我好，也很有道理，但你这样的表达让我瞬间不想理你。我想大家也有类似的经历。很多时候，我们明明出于好心，但由于不会表达，反而适得其反。 学会表达是一件很重要的事情。生活中，良好的表达让亲人、伴侣和朋友间的关系更融洽；工作中，团队内的表达关系着工作效率；展示时的表达影响着项目最终评定，甚至连你毕业时的论文答辩、职级晋升时的考核也考验着你的表达能力。 软件开发亦是如此。大中型软件系统开发工作一般需要大量的软件开发人员统一协作工作，有时开发周期还很长。作为一名合格的程序员，如何理解前辈们设计好的框架和已完成的工作，并让别人快速准确的读懂你写的代码，是一件很重要的事情。因此，本文旨在介绍软件系统的建模和表达方法。 UML（Unified Modeling Language）统一建模语言，又称标准建模语言，是用于软件系统在开发阶段的可视化建模。由于软件系统开发需要经过面向对象分析（OOA）、面向对象设计（OOD）和面向对象编程（OOP）三个阶段，而每个阶段都需要统一的符号设计描述和交流。而UML作为一种通用语言，能有效消除不必要的差异，从而为许多开发人员广泛使用。 本文将介绍UML基本概念、特点、种类和应用。 一、UML基本概念 UML是在软件开发阶段，说明、可视化

Visio 2003 uses UML 1.4, which means that some stereotypes from UML 2.0 simply don't exist, and they need to be modeled by freehand drawing (I may as well be using Photoshop). Does anyone know of an update from Microsoft or an addon to include UML 2.0 (complete - not just class diagrams) in Visio 2003? I found this package: http://www.sdl.sandrila.co.uk/ but judging by their "example" screenshots, I'm going to stay away. If they don't know how to use UML, I'd be surprised if they could implement it correctly ;) This set of Visio stencils and templates for UML 2.0 is excellent: http:/

　　在软件系统中，类不是孤立存在的，类与类之间存在各种关系。根据类与类之间的耦合度从弱到强排列，UML 中的类图有以下几种关系：依赖关系、关联关系、聚合关系、组合关系、泛化关系(继承关系)和实现关系。其中泛化和实现的耦合度相等，它们是最强的。聚合关系和组合关系术语关联关系。 UML类图 　　依赖（Dependency）关系是一种使用关系(use-a)，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。在 UML 类图中，依赖关系使用带箭头的虚线来表示，箭头从使用类指向被依赖的类。 　　关联（Association）关系是对象之间的一种引用关系(has-a)，用于表示一类对象与另一类对象之间的联系，如老师和学生等。关联关系是类与类之间最常用的一种关系，分为一般关联关系、聚合关系和组合关系。关联可以是双向的，也可以是单向的。在 UML 类图中，双向的关联可以用带两个箭头或者没有箭头的实线来表示，单向的关联用带一个箭头的实线来表示，箭头从使用类指向被关联的类。 在代码中通常将一个类的对象作为另一个类的成员变量来实现关联关系。 　　聚合（Aggregation）关系是关联关系的一种，是强关联关系，是整体和部分之间的关系，是 has-a 的关系

experimenting with Cockburn use cases in code I was writing some complicated UI code. I decided to employ Cockburn use cases with fish,kite,and sea levels (discussed by Martin Fowler in his book 'UML Distilled'). I wrapped Cockburn use cases in static C# objects so that I could test logical conditions against static constants which represented steps in a UI workflow. The idea was that you could read the code and know what it was doing because the wrapped objects and their public contants gave you ENGLISH use cases via namespaces. Also, I was going to use reflection to pump out error messages