发信人: leeyg(雷云勾)
整理人: leeyg(2001-06-05 22:31:41), 站内信件
|
静态图之类图
我先起个头，希望这块砖头能引来大块大块的美玉。
UML有5个类的模型图，分别是用例图、静态图（包括类图和对象图）、行为图（包括状态图和活动图）、交互图（包括顺序图和合作图）、实现图（包括构件图和配置图）
类图是面向对象方法的核心技术。我们先从类图开始。
类图描述了系统中的类及其相互之间的各种关系，其本质反映了系统中包含的各种对象的类型以及对象间的各种静态关系。
我们以一个最最简单的例子开始我们的实习（请大家不要小看这个例子），假定我们要实现一个人事管理系统，这个管理系统仅需解决“员工”与“科室”之间问题（人事管理系统真的这样简单就好了！）。
为简单起见，假定“员工”只考虑其“姓名”即可。我们现在用UML来为“员工”与“科室”建模。
“员工”是肯定要建一个类的，在Rose的Logical View中建立一个类，给该类命名为“员工”，选中该类，点击右键后用Add Attribute加入员工的属性“姓名”。
值得指出的是，Rational Rose支持中文。但是在稍后的实习课中，我们会看到，用中文描述的类图，Rose产生源代码时，类名、属性名等也是中文，而我们知道，几乎所有的开发工具都不能支持以中文作类名或其它的变量名。因此，如果你想用Rose自动生成源代码，用Rose（建立的英文模型）将严重影响与中国（绝大多数不懂英文的）客户的沟通，但UML却正是以与用户图示化沟通为优点的，这真是鱼与熊掌的关系。
假定“科室”也是一个类，现在的问题是：
问题一：“员工”类与“科室”类之间的关系是UML中所说的“关联”（association）还是“聚集”(aggregation)，说出你的答案，也说出为什么？（一定要说哦）。
背景：
UML中的“关联”，即Booch方法中的“使用”（uses），或Coad、邵维忠的“实例连接”(instance connection)，Jacobson的“相知关联”(acquaintance association)。
“聚集”，即Booch方法中的“组成”（containing），或Coad、邵维忠的“部分整体”(part-whole)，Rumbaugh的“组成”(composition)。
问题的提出：
从人员的组成来看，“科室”当然是由“员工”组成的，所以要在关联端点加一个菱形。
选择A：
┌───┐ ┌───┐
│ 员工 │ │ 科室 │
├───┤－―――――◆├───┤
│ 姓名 │ │ │
│ │ │ │
└───┘ └───┘
选择B：
┌───┐ ┌───┐
│ 员工 │ │ 科室 │
├───┤＜―――――◆├───┤
│ 姓名 │ │ │
│ │ │ │
└───┘ └───┘
选择C：
┌───┐ ┌───┐
│ 员工 │ │ 科室 │
├───┤－――――＞◆├───┤
│ 姓名 │ │ │
│ │ │ │
└───┘ └───┘
选择D：
┌───┐ ┌───┐
│ 员工 │ │ 科室 │
├───┤◆－―――――├───┤
│ 姓名 │ │ │
│ │ │ │
└───┘ └───┘
选择E：
┌───┐ ┌───┐
│ 员工 │ │ 科室 │
├───┤◆＜―――――├───┤
│ 姓名 │ │ │
│ │ │ │
└───┘ └───┘
选择F：
┌───┐ ┌───┐
│ 员工 │ │ 科室 │
├───┤◆―――――＞├───┤
│ 姓名 │ │ │
│ │ │ │
└───┘ └───┘
但是，真的是仅仅由“人员”就组成了“科室”吗？这种组成关系真的那么明显吗？是否应该存在选择G、H、I：
选择G：
┌───┐ ┌───┐
│ 员工 │ │ 科室 │
├───┤―――――――├───┤
│ 姓名 │ │ │
│ │ │ │
└───┘ └───┘
选择H：
┌───┐ ┌───┐
│ 员工 │ │ 科室 │
├───┤＜――――――├───┤
│ 姓名 │ │ │
│ │ │ │
└───┘ └───┘
选择I：
┌───┐ ┌───┐
│ 员工 │ │ 科室 │
├───┤――――――＞├───┤
│ 姓名 │ │ │
│ │ │ │
└───┘ └───┘
从A到I，你到底选择哪一个，说出你的答案，还必须说出为什么！
----
软件开发是可工业化组织实施的艺术创作 |
|