基于UML2﹒0系统设计思想.docVIP

基于UML2.0的系统设计思想/linco_zhang/article/details/6935516 UML(UnifiedModeling Language)是一种建模语言，更是一种系统分析设计的最佳实践方法。我从2003年开始接触UML，从UML1.1到2.0，感受到了UML的独特魅力，它不仅仅成为在项目和产品分析设计过程中的统一标准，还逐步成为了从需求到测试的最常用公共语言。 我记得在最早接触UML的那段时间，项目组还在辛苦的用着面向结构化的设计思想，写着SRS，画着流程图和数据流图；对OO的设计思想还未真正接触，对于UML只知道系统的设计可以通过9种不同的图来解剖系统，9种图代表了系统的9种纬度，至于如何用到项目中是完全没有概念。 后来，随着Java盛行，OO的思想占据主导，因此接触UML更多了。发觉了解UML越深入就越被其吸引，UML不仅仅是一些图，不仅仅是系统的不同剖面，更是一种业务和系统模型的构造过程。并开始在项目中推动使用UML的标准语言，比如用例图，比如类图。 直到现在，基于UML2.0的应用设计思想仍然是团队中需求、设计、开发人员的主要指导思想。虽然UML1.0的9种图如今扩展到2.0的13种图，然而思想却没有太大变化，在设计中我们依然以用例为驱动，在设计中注重对象的状态变化的分析，注重类的分析和对象间的关系行为分析。 如下图所示，概括了基于UML2.0的APP设计思想。 UML的用法 在我所接触到的项目中，UML是一种设计的指导思想，是一种标准。我经常把UML，CMMI和Prototype合称为项目成功的三驾马车。（现在Agile比较流行，特别是在需求容易变化，项目规模不大的前提下，RUP和Scrum为代表的敏捷方法是可以取代CMMI的一些做法。） CMMI负责对项目的各个过程域提供最佳实践方法指导，通过流程、模版和规范来约束和指导操作行为，以减少项目风险和提升项目质量，同时确保组织级的资产成为可持续发展的财富。 Prototype是对需求过程最好的一种检验，我一直认为需求捕获和分析的能力是项目是否能够交付的最大保障。所以，我迷信通过Prototype来与用户迭代的确认，与开发测试人员按原型来验收成果。 UML不用多说了，是指导需求，设计和开发过程的一种思想。 另一方面，Martin把UML的用法从深浅分作三个层次： 草稿：是最常用的一种方法，主要用于沟通系统的某些层面。如果希望使用的更深入一些，可以通过正向工程和反向工程，实现模型和程序框架的互相推导。 蓝图：展现完整的系统设计细节，能够指导开发。与草稿的区别在于，草稿并不是完整，而是注重强调需要交流的重点；而蓝图是完整的，把程序工作变得更简单。草图是探索式的，蓝图是系统性的。 程序：以MDA（模型驱动开发）为基础，能够自动从PIM转化为PSM，再从PSM转化为程序代码的过程。 下面谈谈从我的理解如何把UML的思想映射到项目的各个过程中，这些图又如何配合起来使用。 UML2.0包括13种图，其中类图，组件图，合成结构图，部署图，对象图和包图被归于为静态结构图；活动图，用例图，状态机图，时序图，通讯图，交互概览图和时间轴图归属于动态行为图。 在需求分析阶段，可以用到的是用例图，类图，活动图和状态图。 在设计阶段，一般用到类图，时序图，包图，状态图和部署图。 用例图（use case） 用例图，用来描述人机交互，与系统的互动。是定义和描述需求的最好方法，同时一个好的用例设计，一定是将用例映射到系统实现的类，用例说明了类的迁移和操作。 ?如下面的用例图所示， 在用例中描述了这些内容： 用例的关联角色是 Customer系统边界是 TeeMall OnlineSystem基础用例是 Place OrderPlace Order用例包了(Include)了Supply Customer Data ,Order Product, Arrange Payment用例Request Catalog用例是Place Order用例的扩展(Extend)用例Arrange Payment用例概括了Pay Cash和Arrange Credit两个子用例? 状态机图（State Machine） 状态机图是类的对象生命周期进行建模。状态机是由状态和迁移构成，是对象局部化视图。 通常，使用状态机图来反映对象状态的变化和其生命周期的模型。比如，以一个信用卡自助电影票购买终端的状态控制机为例。 在一般情况下，终端为空闲状态Idle； 当用户插入卡后，进入买票流程。 状态1：验证。信用卡密码验证，如果验证失败，则购票过程结束，终端退出用户的信用卡，状态变为空闲。 状态2：选择。信用卡密码验证成功后，进入选择状态。选择电影场次和座位，并添加到自己的选择箱中。 状态3：确认