项目管理实践及课程内容设计具体指导——UML静态数据和动态性建模技术性在详尽设计中的运用实例
1.1 在软件应用系统的详尽设计时要充足运用UML静态数据和动态性建模技术性
1、再度了解UML技术标准中的“统一”的含义
UML是一种数据可视化、作用标准和文本文档化的手机软件系统剖析和设计中的统一建模语言表达，UML中的“统一”的涵义是可以让软件应用系统开发者应用一种规范的方式 开展软件应用系统的研究和设计，而且它是一种开放性的规范。
2、为啥面向对象分析、设计和开发设计完成中大力提倡运用UML技术标准
（1）完成新项目组员中间的无模棱两可地交流和沟通交流
在软件应用系统项目分析报告、设计和开发设计完成流程中，开发者运用UML 的意义取决于它可以完成精英团队中的每个组员间无模棱两可地交流和沟通交流——由于人们的自然语言理解自身是难以做到无模棱两可的表述，因而必须 UML 这类图形界面的语言表达的辅助工具协助。
（2）在课程内容设计的项目开发设计时要充足运用UML静态数据和动态性建模技术性
在课程内容设计的项目开发设计中，创作者明显地规定阅读者要运用UML所供应的各种各样技术标准完成所研发的软件应用系统新项目的剖析、设计和开发设计完成等全过程，这并没有规定阅读者为了更好地UML而运用“UML”——由于UML的统一建模的体制把握住了软件应用系统的实质，它可以界定软件应用系统的系统架构（根据UML分层次包图）、并根据数据可视化建模技术性完成将业务处理方式变换为电子计算机中的代表方式，并凭借适用UML的Case专用工具还能协助开发者协助转化成相匹配计算机语言的总体目标编程代码——如Java和C 等方式。
因而，阅读者对UML技术标准的了解和把握——这包含UML的首要特点和表达方式、应用UML的具体的目地、UML中包含哪几个方面的主视图及其在UML中是怎么叙述手机软件系统的实体模型等领域的基础知识內容是阅读者学习培训的关键。
3、虽然UML也归属于“语言表达”，但它与电子计算机计算机语言是根本不一样的
统一建模语言表达UML自身并没什么太深奥难懂的专业术语，因而阅读者在学习培训UML时并不会有哪些很大的艰难。但阅读者必须确定的是，虽然UML也归属于“语言表达”，但它与阅读者平常学习培训的电子计算机计算机语言是根本不一样的——电子计算机计算机语言是选用句子及字符符号完成对问题的叙述；而UML则是选用符号图片完成对手机软件系统中的各种各样构成原素开展叙述，而且UML中的各种各样符号图片都被授予有一定的词义和英语的语法标准——阅读者务必严格执行这种英语的语法。
因而，阅读者在学习培训UML时假如可以确立并区别UML与基本的电子计算机计算机语言所具有的这种区别，将可以有利于阅读者对UML的了解和恰当地运用于课程内容设计的手机软件系统新项目研发的研究和设计工作上。自然，更改这种观点和思维模式针对UML的新手而言是有一定的困难的。
为了更好地可以真实地掌握和把握UML中的各种各样主视图在软件应用系统开发设计中的详细运用，期待阅读者在课程内容设计的项目开发设计中一定要运用UML、技术标准、并感受UML中的各种各样主视图的真正的含意。因而，假如用户期待可以系统和深层次地学习培训和把握UML及UML在手机软件系统剖析和设计中的详细运用，可以参照创作者的J2EE新项目实践“UML及设计方式”一书里的相关章节目录內容。
此外，阅读者在工程开发设计完成流程中，不应该立即依据对手机软件系统的设计結果开展程序编程完成，还一定要对手机软件系统设计的效果开展构建和提升以确保对手机软件系统的设计結果是有效和恰当的、并达到手机软件系统要求中的各类需要的。
4、了解软件应用系统详尽设计有关的具体工作职责
软件应用系统设计中的详尽设计是对概述设计环节中所形成的设计結果进一步精华和优化的设计全过程，设计工作人员工作的首要关键和首要的工作职责为：
操作界面设计、每个控制模块部件类的组员设计、业务作用完成工艺的有效应用等內容，及其典型性控制模块中内部结构的优化算法设计等內容。自然，设计工作人员也还应当考虑到如下所示层面的问题：
（1）考虑到软件应用系统中各层的具体化的工艺完成和选用哪些方式的运用架构
（2）软件应用系统中每个层中的每一个程序流程类的详尽界定，这包含程序流程类的组员特性和组员方式
1.2 软件应用系统业务解决层中的业务逻辑性建模及业务作用类的设计
1、软件应用系统业务层部件中业务类的设计
软件应用系统中的业务层也称之为业务系统层，优良的业务层中的各种部件类设计可以促使运用系统中的表示层选用不一样的完成技术性而不危害到系统中的业务层的基本功能完成。
（1）什么叫好的业务程序模块的设计結果
一个有效的业务程序模块的设计結果，一般应当具备如下所示好多个基本上的特点规定——他们是确保做到高内聚力和低耦合的设计总体目标的基础标准：
1）扩展性（Extensibility）——软件应用系统可以成本低地拓展和加上新的运用作用；
2）操作灵活性（Flexibility）——软件应用系统对编程代码的改动可以稳定地产生，不容易造成改动大批的基本功能完成编程代码的情况；
3）可插进性（Pluggablity）——开发者非常容易将一个程序流程类从软件应用系统中抽出去，与此同时将另一个有一样插口的完成类加上进去而进行系统作用建立的更换。
（2）欠佳的业务程序模块的设计結果
1）欠缺操作灵活性——开发者难以在软件应用系统中加上新的作用，由于每一处的修改便会直接影响到软件应用系统中太多的功能模块而造成“牵一发而动全身”的维护保养改动的实际效果，这时则觉得该软件应用系统欠缺操作灵活性；
2）易损性——当开发者在软件应用系统中的某点干了修改后，却造成软件应用系统的其余的众多控制模块也发生了“连锁加盟”性的变动而追随改动——多诺米骨牌效用的“链式反应”；
3）不能器重性——难以在其他软件应用系统程序流程中器重本软件应用系统中的某一程序模块，由于无法将该功能模块从目前的软件应用他程序流程中单独地提炼出去，其首要因素是因为耦合有其余的作用类的编程代码——“挖到箩卜拉出泥”。如下所示示图为某一Web运用系统中的Web网页页面完成的编码部分截屏——HTML标识和Java解决逻辑性编码掺杂在一起。
2、怎样完成将业务层和表示层互相分离出来
自然，软件应用系统的设计和开发者为了更好地能做到“高内聚力和低耦合”的软件应用系统设计的主要总体目标，除开要遵循面向对象编程程序流程类设计中的五大设计标准之外，还能够运用下边列举的各类类型的GOF编程代码设计方式和设计方法以简单化对软件应用系统的设计和基本功能完成全过程：
（1）命令模式（Com ** nd）
（2）分销模式（Proxy）
（3）门面模式（Facade）
（4）消息队列体制
根据运用这种设计方式可以做到根据“不大的设计更改”就可以解决比较大的“手机软件系统要求”的变动的设计实际效果。
3、系统业务解决层在设计时要遵循面向对象编程的“封装形式”和“防护”的设计标准
（1）最先要思考与数据信息相关的业务实体线的封装形式
针对业务数据信息的表明方法，为了更好地可以遵循面向对象编程程序流程类设计中所提倡的封装形式的观念，一般选用业务实体线部件类包裝每个业务数据信息而造成出VO（Value Object）类；自然，也还需要考虑到业务数据信息的存储方法，一般可以利用目标关联投射（O/R Mapping）技术性来完成将业务实体线投射到关系数据库表格中，业务实体线中的每个组员特性投射到关系数据库表格中的字段名。
（2）次之再考虑到怎样设计业务逻辑性的机构方法
面向对象编程的程序流程类设计中提倡面对插口程序编写完成，因而需要要为软件应用系统中的每个业务作用类给予相应的业务解决办法的接口定义；随后再根据每个业务作用的插口给予业务插口的主要完成类——进而保障了插口的平稳而对于差异种类的业务解决的必须给予不一样的基本功能完成，提升了功能模块的操作灵活性。
假如在软件应用系统的业务完成类中还牵涉到数据信息浏览的一致性等作用规定时，则应当考虑到在软件应用系统中运用事务管理的工艺及考虑到怎样实际地完成事务管理——最好是可以运用面对横切面程序编写（AOP）的观念分离出来软件应用系统的业务作用完成程序流程类和事务管理作用完成程序流程类中间的耦合关系。
（3）最终再考虑到以什么方法向外部（手机客户端）给予业务作用服务项目
软件应用系统的设计工作人员关键要考虑到怎样向客户端程序给予本软件应用系统的业务作用服务项目，并尽量与客户端程序造成疏松耦合的关系。
因此，软件应用系统的设计工作人员可以按照不一样的使用要求充足运用工厂模式以防护对生产经营者目标案例在建立领域的依靠、运用命令模式分离出来服务项目的请求者对业务的主要完成者的太强的依靠、运用分销模式分离出来服务项目的请求者对业务的服务提供者的立即依靠、运用模板模式分离出来共功能完成编码和人性化的基本功能完成编码等设计方式而最后超过分离出来服务项目的提供和服務的请求者中间的耦合关系。
4、银行帐户信息化管理运用系统新项目详尽设计中的UML类图
软件应用系统的设计工作人员经过对软件应用系统的概述设计环节所形成的“细粒度”程序流程类进一步地优化其设计結果，并为不同程序流程类定义出类中所涉及到的组员特性、方式等构成组员，最终造成出“粗粒度”情况的软件应用系统的详尽设计程序流程类，随后再选用UML技术标准的类图叙述出每个作用类相互关系和构成构造。
银行帐户信息化管理运用系统新项目中的详尽设计中的最后的程序流程类设计結果请见下面的图所显示——为了更好地节约本文章内容的篇数，一样也潜藏了一部分类中的组员方式沒有展现出。
1.3 UML动态性建模技术性在软件应用系统业务步骤的剖析、叙述和设计中的运用
1、应用软件应用系统中的动态性建模体制及实际完成的运用实例
在软件应用系统UML静态模型的基本上创建出相对应的UML动态性实体模型，而UML动态性实体模型表述了软件应用系统随时长变动的个人行为，这种情形是用从UML静态数据主视图中提取的系统一瞬间值的变动来叙述的。UML动态性实体模型主要包含UML顺序图、UML协作图、UML状态图和UML活动图，软件应用系统的设计和开发者运用这种UML技术标准的主视图可以有利于剖析软件应用系统在运转时的个人行为、证实和改动软件应用系统的静态数据构造，做到确立软件应用系统的基本功能建立的总体目标。
2、运用UML状态图进行对软件应用系统中的不同关键业务流的动态变化以具体指导后面的程序编写完成
UML状态图可以用于叙述一个特殊目标（例如参加者）的任何很有可能情况以及造成情况转换的各类事情，而且大部分面向对象编程设计技术性都提倡运用UML状态图表明单独目标在其周期中的多种有可能的个人行为，与此同时也表明了该实体线怎样按照现阶段所在的情况而作出的各种各样反映。
但在什么场所下应当要运用UML状态图？一般可以遵循如下所示的标准——当软件应用系统中的特殊目标个人行为的更改和情况相关时才应当建立出UML状态图。UML状态图在即时系统开发设计中使用的比较多，自然还可以用以协助设计软件应用系统的操作界面。
下面的图所显示为银行帐户信息化管理系统中的注册账号客户的状态图，根据状态图可以更好的掌握类的信息个人行为，软件应用系统的开发者在编号前就能掌握繁杂的业务逻辑性完成全过程。
在UML的技术标准中一般把初始值置放在UML状态图的左上方、而且初始值被建模成一个实芯圈；而状态图中的停止情况一般被置放在右下方，而且最后情况被建模为一个带界限的实心圆；在同一个状态图中只有有一个初始值，但可以有好几个停止情况——请见图以上实例图。
3、运用UML活动图进行对软件应用系统中的不同关键业务流的动态变化以具体指导后面的程序编写完成
阅读者最先要认知到“测试用例叙述”和“主题活动实体模型”叙述中间普遍存在着至关重要的差别，测试用例叙述仅仅从软件应用系统的“外界参加者”的视角入手开展编辑和叙述的，它只描述软件应用系统中的每个测试用例中间的“静态数据的关联”，而不能够叙述软件应用系统中的每个“参加者”、“每个测试用例”的信息个人行为。
而主题活动实体模型中的UML活动图则因为使用的是以软件应用系统的“内部结构完成”的视角入手来编程和叙述的，因而应用UML活动图可以表明由软件应用系统内部结构所形成的各种姿势；自然，软件应用系统的设计工作人员还可以运用UML活动图为测试用例参加者对软件应用系统的操控方式开展建模、而且可以图例出不一样作用中间的前后左右关联。
下面的图所显示为某一BBS社区论坛系统中的注册账号客户要求变成论坛版主的UML活动图（带泳道的UML活动图），在UML中的活动图实质上便是面向对象方法程序流程设计方式中的流程表，因而还可以图例某一测试用例的业务完成全过程和反映好几个目标互相互动情况。
4、运用UML协作图进行对软件应用系统中的不同关键业务流的动态变化以具体指导后面的程序编写完成
UML中的协作图可以表明在指定区域环境中相应的一组目标间的紧密配合、及其一种互动影响——为完成某一实际操作或做到某类結果而在目标间互换的一组信息。
因为UML协作图也是一种互动图，但根据这种类别的互动图，可以展现出由一个测试用例界定的一个系统事情及其在其中的一组目标与其他组目标中间是怎么彼此之间开展合作的信息内容。因而，可以将UML协作图视作UML对象图的拓展——它除开可以呈现出软件应用系统中的各个对象间的关联关系以外，还能够显示出对象间的消息传递。
但UML协作图与UML顺序图的不同之处在于，在UML协作图中不能体现出消息的先后顺序——因为UML协作图主要是显示对象之间的交互关系和链接关系，它并不将时间作为单独的一个坐标维度表示出。因此，要对UML协作图中的消息采用数字进行编号以表明这些消息产生的先后顺序。
下图所示为银行账户信息管理系统中的转账用例的UML协作图，在该协作图中对消息采用数字编号以体现各个消息产生的先后顺序，该UML协作图主要表示储户（注册用户）在完成转账时，会涉及到trainmitAccount表单、AccountManageServlet控制层组件、AccountManageBean业务层组件和AccountManageDAOJDBCImple等DAO组件对象，同时还要与这些对象发生协作（关联）关系。
5、为什么要应用UML技术规范中的协作图
（1）利用UML协作图能够辅助软件应用系统的分析人员分析软件应用系统中复杂的交互操作状况
虽然应用UML顺序图可以很好地表达操作和行为方面的信息，而且在UML顺序图中的时间关系也表达得比较清楚。但是，当业务流程关系非常复杂的时候，再采用UML顺序图来描述就会很复杂而导致UML顺序图中的各个对象及关系太密集而不清晰，这样反而不利于对软件应用系统相关问题的表达和描述。
所以，对于这些应用情况下的软件应用系统的分析，软件应用系统的分析人员更应该要使用UML协作图来表达复杂的业务流程，将会使表达更清楚和更简洁。在Rose的UML实现工具中可以依据UML顺序图转换创建出对应的UML协作图，如下示图为Rose的UML实现工具中提供的转换功能菜单。
（2）利用UML协作图简化对软件应用系统中的各个对象间的关联建模
由于UML协作图只对相互间具有交互作用的对象和对象间的关联建模，软件应用系统的分析人员在UML协作图中可以忽略其它对象和关联关系的描述。从而使得软件应用系统的分析人员能够更好地描述出实现某个用例时所需要涉及的各个对象以及它们之间的关联关系方面的信息。如下示图为某个BBS论坛系统中注册用户发表文章的UML协作图，该UML协作图图示了文章发表的复杂业务流程和相互关联的对象。
扫码咨询与免费使用
申请免费使用