《用UML建模需要注意的问题》由会员分享，可在线阅读，更多相关《用UML建模需要注意的问题（3页珍藏版）》请在金锄头文库上搜索。
1、用 UML：芸模需要注意的问题用UML建模时，对软件开发过程是有要求的，必须是用例驱动，以架构为中心，迭代和递 增的开发，如果软件开发组织的软件开发过程不能满足这三点要求，那么UML的使用效果 就会大打折扣，下面详细论述：一、用例驱动用例驱动意味着为系统定义的用例是整个开发过程的基础。用例在多个核心工作流程中都发挥了作用。1、用例的概念可用来表示业务流程，我们称这种用例的变体为“业务用例”。2、用例模型是需求工作流程的输出结果。在这一早期流程中，需要通过用例来建立用户希 望系统完成的任务的模型。这样，用例构成了一个重要的基本概念，客户和系统开发人员都 必须认可这个概念。3、在分析设计中，用例是
2、在设计模型中实现的。您需要生成用例实现来说明在设计模型中 如何通过对象的交互来执行用例。此模型根据设计对象来说明所实施系统的各个组成部分， 以及这些部分如何通过相互作用来执行用例。4、在实施阶段，设计模型就是实施的规约。由于用例是设计模型的基础，所以用例需通过 设计类来实施。5、在测试期间，用例是确定测试用例和测试过程的基础。也就是说，通过执行每一个用例 来核实系统。6、在项目管理过程中，用例被用来作为计划迭代式开发的基础。7、在部署工作流程中，它们构成用户手册阐述内容的基础。用例也可用来确定产品构件如 何排列组合。例如，客户可通过将用例进行某种组合来配置一个系统。二、以架构为中心构架之所以重
3、要，原因有以下几点：1、它使您可对项目进行并保持理智的控制，应付项目中复杂多变的情况，同时保持系统的 完整性。一个复杂的系统不仅仅是其各组成部分之和，也不光是一连串没有关联关系的、很小的技巧 决定。它必须依靠某种连贯统一的结构来有条理地组织那些部分，并且提供准确的规则，使系统发展过程中，其复杂程度不会膨胀，超越人类的理解力。通过建立用于讨论设计问题的一套公共参考材料和一个公共词汇表，构架提供了增进交流和 理解的手段。2、它是大规模复用的有效基础。通过明确阐述它们之间的主要构件和关键接口，构架为您决定重复使用提供依据，包括内部 复用（确定公用的部分）和外部复用（并入现成的构件）。它还允许更大规模
4、上的复用：构 架本身的复用，用于处理同一领域中的不同功能。3、构架还可作为项目管理的基础。项目计划和人员配备是根据主要构件的类别组织进行的。基本的结构决策是由一个人员组成 相对固定的构架小组作出的，他们不是分散的。而开发活动则被分配给若干个小组，每个小 组负责开发系统的一个或若干个部分。三、迭代和递增的开发迭代式方法一般要优于线性或瀑布式方法，其原因很多。1、允许变更需求。需求有时会变化，这常常给项目带来麻烦，它们会导致延期交付、工期 延误、客户不满意、开发人员受挫。2、逐步集成元素。在迭代式方法中，集成可以说是连续不断的。过去在项目结束时要占到 整个项目工作量的那段较长的、不确定的且棘手的时
5、期，现在分散到六至九个集成部分中， 每一部分要集成的元素都比过去少得多。3、及早降低风险。因为风险一般只有在集成阶段才能发现或得到处理。在初期迭代时，检 查所有的核心工作流程，对项目使用的工具、市售软件及人员技能等许多方面进行磨合。过 去认定的风险可能被证明不再是风险，而又可能出现一批新的未曾怀疑过的风险。4、有助于组织学习和提高。团队成员有机会在整个生命周期中边做边学，各显其能。测试 员可以早一些开始测试，技术文档编写员可及早开始编写，其他人也是如此。如果是非迭代 式开发，这些人在初期只能制定计划或培训技能，空等着开始他们的工作。培训需求等也可 在评估复审中尽早提出。5、提高复用性。因为分部
6、分设计或实施比起预先确定所有共性更容易确定公用部分。确定 和开发可重复使用的部分并非易事。早期迭代中的设计复审可使构架设计师确定毋庸置疑的 潜在复用部分，并在以后的迭代中开发和完善这些公用代码。6、生成性能更强壮的产品。因为在多次迭代中您总是不断地纠正错误。在产品脱离先启阶 段后的初期迭代中仍然可以发现缺陷。性能上的瓶颈可以尽早发现并处理，而不象在交付前 夕，此时已来不及处理。7、容许产品进行战术改变。例如同现有的同类产品竞争。可以决定采用抢先竞争对手一步 的方法，提前发布一个功能简化的产品，或者采用其他厂商的已有技术。8、迭代流程自身可在进行过程中得到改进和精炼。一次迭代结束时的评估不仅要从
7、产品和 进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待改进之处，以便在下 次迭代中更好地完成任务。通常在软件开发过程中，迭代在数量、持续时间和目标上都是按计划进行的。参与者的任务 和职责都已确定好。对进度进行的目标评测都将记录备查。从一次迭代到下一次迭代确实会 存在返工现象，但返工也是严格按规定进行的。四、使用不当的问题很多企业员工在使用UML的过程中，只是进行了领域建模，没有进行用例建模，这样是不 能最大可能地发挥UML的优势的，因为该组织的软件开发过程不是用例驱动的。如果软件开发组织的软件开发过程不能满足上述三点要求，那么UML的使用效果就会大打 折扣。也会产生一些问题，有
8、些组织在使用UML之后，发现前期花很长时间设计的模型到 了项目的中后期和真正的开发成果相去甚远，以至于全都束之高阁了，如果产生这样的问题， 就应该仔细研究一下组织的软件开发过程，是否满足上述三点要求，如果软件开发过程不满 足迭代的开发，模型没有随着进度改进，这种问题就很容易出现。UML2.0和MDA （模型驱动架构）提出了一些解决开发周期前期和后续的模型不一致问题的 方法，就是通过模型的转换来完成模型的自动变更，而不是对各个抽象层次的模型全部进行 修改，但MDA为大部分人所接受还需要些时日。五、总结综上所述，UML虽然是软件建模的有利武器，也要遵循一定的规则来使用，否则就不能很 好地发挥它的价值，也会事倍功半。理解UML使用的前提，并认真按照这些方法进行实施，相信会有理想的效果。六、参考资料1. Rational Unified Process documents
