基于UML描述的分析与设计
一,分析与设计思想概述
二,面向服务架构
三,MDA支持环境
四,UML基本元素
五,UML分析与设计过程
六,实战锦囊
一,分析与设计思想概述--MDA
在分析与设计思想的发展中有两个普遍的发展方向,一个是架构方面的,一个是方法学方面的,我们可以从中有所收获.
第一个就是MDA(模型驱动架构),简单说MDA认为架构设计师首先要对待创建的系统有一个形式化的UML的模型.MDA首先给出一个平台无关的模型来表示系统的功能需求和use cases,根据系统搭建的平台,架构设计师可以由这个平台无关的模型得到平台相关的模型,这些平台相关模型足够详细,以至于可以用来直接生成需要的代码.
一,分析与设计思想概述--MDA
在UML2.0的规范中,提到了一个MDA(Model Driven Architecture)的概念.在众多的软件平台中不知该如何选择,已经演变为当今软件开发的主要难题.MDA的存在目的就是为了解决这个问题.通过MDA技术,一个UML的模型可以是平台无关的,称为PIM(Platform-Independent Model),也可以是和特定平台相关的,称为PSM(Platform-Specific Model).利用平台技术的软件商,可以专注于自己的领域,集中描述业务功能,业务规则,而无须考虑特定的技术,构建出一个PIM,然后,通过支持MDA的工具,将PIM转换(通过不同Profile进行映射)为一个或多个PSM.这时候的模型仍然是UML的.但是,这个转换过程虽然有工具的辅助,但仍然需要外力的介入.接下来,开发工具将会从PSM中产生可执行代码.这就是MDA的思路,它把以往以程序为中心的开发模式转变为以设计为中心的开发模式.
一,分析与设计思想概述--MDA
一,分析与设计思想概述--MDA
其中MOF为元对象工具(MetaObject Facility,简称MOF) , 公共数据仓库元模型CWM(Common Warehouse Metamodel )
以往的重用,往往是基于代码的,例如算法的重用,界面组件的重用,却往往没有将重用提升到设计的层次上.MDA为我们建立可重用的框架提供了一个很好的指导.注意上面的这副图,最外面的两层就表达了MDA可以用于设计重用的基本理念.倒数第二层的含义是利用MDA来进行通用软件(例如事务,目录服务)的模型设计,倒数第一层则表示MDA可以用于特定业务领域的设计建模.可以想象,今后软件公司中的最有价值的资产,就是这些设计模型.
一,分析与设计思想概述--AM
分析设计思想的另一个基础是敏捷建模AM (Agile Modeling) ,其中非常有名的方法是极限编程(XP).象XP这样的AM提供了在需求未知或者多变的环境中创建软件系统的过程.XP要求在开发团队中要有一个用户代表,他帮助书写测试来指导开发人员的日常工作.开发团队中的所有成员都参与到设计之中,并且设计要尽量小并且非形式化.AM的目标是仅仅创建用户想要的,而不是在一些形式化模型上耗费工作量.AM的核心思想就在于其敏捷性-处理需求变更的敏捷性.AM的主要弱点是其规模上的限制,例如,XP在一个小团队和中型项目中效果不错,但是当项目规模增大时,如果没有一个一致的清晰的计划,项目成员很难把握项目中的方方面面.
一,分析与设计思想概述
MDA与AM的关系
从表面看来,MDA和AM是相对立的-MDA假定需求是固定的,而AM恰恰相反.MDA的中心是形式化的模型,而AM恰恰要避开它们.MDA的核心就在于在设计阶段系统就已经完全描述,这样,在创建系统的时候,很少有错误解释的可能,模型也就可以直接生成代码.但MDA的方式(UML)有一些局限性:首先,MDA假设在创建模型之前,业务需求已经基本描述,而这一点,在当前典型的动态业务环境中几乎是不可能的.第二,MDA没有一个反馈机制.如果开发人员对模型有需要改动的地方,并没有提供给他们这么一个途径.
建议:1,在开发新的中,小规模系统时,使用AM模式
2,可以在MDA方式中,融入AM模式
二,面向服务架构(SOA)
SOA (Services-Oriented Architecture)是目前IT行业中面向企业,个人服务的关键技术,在此方式下,分布式计算将网络上分布的软件资源看作是各种服务.面向服务架构是一种不错的解决方案,但这种架构不是什么新思想;CORBA和DCOM就很类似,但是,这些过去的面向服务架构都受到一些难题的困扰:首先,它们是紧密耦合的,这就意味着如分布计算连接的两端都必须遵循同样API的约束.例如,如果一个COM对象的代码有了更改,那么访问该对象的代码也必须作出相应更改.其二,这些面向服务架构受到厂商的约束.Microsoft控制DCOM自不必说,CORBA也只是一个伪装的标准化努力.

下一页