发信人: leeyg(雷云高)
整理人: leeyg(2001-06-05 22:31:41), 站内信件
|
UML是一种通用的建模语言，可供所有建模者使用，因此，它必须照顾所有使用不同建模方法的建模者的使用；UML是一种可精确描述客户需求的语言，具有很强的严密性，严密到甚至可以一定程度地借助工具生成部分代码，因此，UML具有非常精确的语义。
但是，凡事都有两面性，这些数量众多、语义精确的模型也一定程度上影响了和用户的交流。UML的白皮书有多厚我们都知道，你总不能要求用户先学习完这些语义、表示法后再与专业人员一起沟通吧。就我们前面所说的“约束”来说，我们这些吃这碗饭的，为了了解这个概念又付出了多少呢？正如《UML参考手册》上说，“UML提供了多种模型，不是在一天之内就能够掌握的。它比先前的建模语言更复杂，因为它更全面”
个人认为，UML极强的表达能力及精确的语义定义，能够切实消除用户与系统分析员、系统分析员与开发人员、开发人员与开发人员之间的歧义，应用UML作为建模语言是非常有必要的，UML必将是个趋势。但是，我认为应尽可能地用UML最基本的概念描述系统，除非很有必要，否则尽量少用相对用户来说不易理解的图符。
理论上说，如果系统是用纯面向对象的开发方法（可能除主程序不是类外）开发的，就是说系统中都是用类来实现的，那么类图中的每一个UML元模型都应该可以转换为类，那些晦涩的什么约束之类的是可以转换为类的。
所以，如果建模方法得力，用UML最简单的图符应该也可以清晰表达客户的需求。
下面就以约束关联为例，来说说怎样将用户较难理解的关系以最简单的形式表达出来（简单即是最好！这可是本人一直信奉的信条哟）
我们知道，通常，A类中表达对B类的关联是通过在A类中设立B类对象的属性来实现的。根据我上面所说的用实现反推模型的逆过程思考方法，我认为，
类中的属性代表的其中一种意义就是与属性的类型所代表的类的关联（远高建模方法）
比如说，“科室”类中的“科长”属性，其类型是一个“员工”类，那么，“科室”类的“科长”属性已经隐含了“科室”类与“员工”类的一种关联。
说是“其中一种”，因为并不是说属性的全部意义都是关联，关联仅是其中的一种。
根据上面的原则，一个实用的建模方法是：
将关联的角色建模为类的属性，可以简化甚至取消关联。（远高建模方法）
约束关联也是一种关联，只不过是一种特殊的关联，它有2个以上的元素。我们应用上面的方法作一个对比。
模型一：
┌───┐科员 ┌───┐
│ 员工 │────────◇│ 科室 │
├───┤(1..n) ↑ (0..n)├───┤
│ 姓名 │ ┊ │ 名称 │
│ │ ┊{子集} │ │
│ │ ┊ │ │
│ │ 科长 │ │
│ │←────────│ │
└───┘(1..n) └───┘
模型二：
┌───┐ ┌─────┐
│ 员工 │ │ 科室 │
├───┤ ├─────┤
│ 姓名 │------------------│名称 │
│ │ │科长：员工│
│ │ │科员：员工│
│ │ │ │
│ │ │ │
└───┘ └─────┘
哪一个更清晰？哪一个更容易实现？哪一个更符合面向对象的分析与设计？
科长对科员的约束封装在“科室”里，使“科室”与“员工”的耦合度减少到最低。“科室”对象的模型更符合客观现实，内涵更丰富。整个模型更清晰明了。
我之所以说，“简化甚至取消”，事实上，如果完全取消“科室”类与“员工”类之间的联线，按我上面理论，是可以的，但是，应用UML的语义，加一条关联线，客户知道科室和员工是有关联的，（这就够了，客户并不想知道也没有义务去知道什么“子集”的什么“约束”）我们并没有防碍与用户的沟通，达到了与客户沟通的目的，也更容易在设计中实现，兼顾了设计人员的要求。
这里有一个问题，加了一条线后，Rose等UML工具在产生代码时会在产生这个关联时自动在“科室”中产生一个“员工”属性，这个属性是多余的。这好办，在关联的“科室”端加一个箭头就解决了，这个导航也清楚地表达了，“员工”的一个职责就是要说明员工是属于哪个“科室”的。
以上的一些想法，请大家的指正指正。
----
软件开发是可工业化组织实施的艺术创作 |
|