Associations 数据驱动的关联视图与行为驱动的关联视图
在《UML用户指南》第5章中,我发现了以下内容:Associations 数据驱动的关联视图与行为驱动的关联视图,associations,uml,class-diagram,Associations,Uml,Class Diagram,在《UML用户指南》第5章中,我发现了以下内容: 要建立结构关系模型 对于每对类,如果需要从一个类的对象导航到另一个类的对象,请指定两者之间的关联。这是关联的数据驱动视图 对于每对类,如果一个类的对象需要与另一个类的对象交互,而不是作为操作的参数,请指定两者之间的关联。这更像是一个行为驱动的关联视图 这是我对第一类关联的理解,关联的数据驱动视图,通过以下示例:一个类,User,有三个属性,其中一个是另一个类,Address class User { String firstName
要建立结构关系模型
- 对于每对类,如果需要从一个类的对象导航到另一个类的对象,请指定两者之间的关联。这是关联的
数据驱动视图
- 对于每对类,如果一个类的对象需要与另一个类的对象交互,而不是作为操作的参数,请指定两者之间的关联。这更像是一个
行为驱动的关联视图
这是我对第一类关联的理解,
关联的数据驱动视图
,通过以下示例:一个类,User,有三个属性,其中一个是另一个类,Address
class User {
String firstName;
String lastName;
Address address;
}
class Address {
String streetName;
int streetNumber;
String postalCode;
}
上述情况的UML图为:
请注意,User
的第三个属性转换为association end(据我所知,因为它是Address类类型)
我的问题是:
1-这是对关联的数据驱动视图的正确解释吗
2-如何看待
行为驱动的关联视图
?有没有一个例子可以解释这一点?数据驱动的关联是具有聚合性、多样性、可导航性和所有这些特性的正常关联。它们定义明确
显示属于一个类的函数并将其他类实例用作参数或结果时使用的行为驱动关联。这里也属于任何复杂的连接,例如“侦听”、“注册”等等。它们显示为依赖项,可能带有一些附加字母,例如(用法)。它们没有严格定义,不能用于代码生成
不要太相信“UML用户指南”这个词——它们都只是书,不是UML标准的一部分。他们不是圣人,充满了作者的个人观点(唉,谬论)。UML标准中没有任何地方禁止使用依赖项来显示某些参数列表中其他类的使用