2.6 用UML 建模
用UML 语言建造系统模型的时候并不是只建一个模型在系统开发的每个阶段都要建造不同的模型建造这些模型的目的也是不同的需求分析阶段建造的模型用来捕获系统的需求描绘与真实世界相应的基本类和协作关系设计阶段的模型是分析模型的扩充为实现阶段作指导性的技术上的解决方案实现阶段的模型是真正的源代码sourcecode 编译后的源代码就变成了程序最后是展开模型它在物理架构上解释系统是如何展开的虽然这些模型各不相同但通常情况下后期的模型都由前期的模型扩展而来因此每个阶段建造的模型都要保存下来以便出错时返回重做或重新扩展最初的分析模型如图2-16 所示
分析模型 设计模型 实现模型 实现模型
系统模型
图2.16 用多个模型描述的系统
UML 语言具有阶段独立性也就是说同样的通用语言和同样的图可以用在不同的阶段为不同的事情建模这使得建模者能把更多的精力放在考虑模型的结构和适用范围上注意建模语言只能用于建造模型不能用于保证系统的质量第四章介绍若使用UML 语言建模建模工作一定要依照某个方法或过程进行因为这个方法或过程列出了应进行哪些不同的步骤及这些步骤怎样实现的大纲建模的过程一般被分为以下几个连续的重复迭代阶段需求分析阶段设计阶段实现阶段和展开阶段与实际的建模工作相比这是一个简单的建模过程通常情况下一组人聚在一起提出问题和讨论目标就已经开始建模了他们一起讨论并写出一个非正式的会议记要记录可能要建造的模型的构想和应有怎样的变化记录会议内容的工具也很不正规通常在笔记本和白板上书写这种会议一直要持续到参与讨论的人感觉这些基本的模型具有一定的可行性了才会进入下一阶段这时形成的模型称为早期的假说把假说用某一CASE 工具描述假说模型就组织起来了同时按照建模语言的语法规则构建一个真实的图也是可行的了再到下一阶段时前期模型会被更详细地描述这个阶段主要完成的工作是细化解决问题的方案和文档提取更多的解决问题需要的信息这个工作可能需要几经反复才能最后完成通过这个阶段的工作假说也逐渐变成一个可使用的模型了再接下来的步骤是集成integration 和验证verification 模型集成就是把同一系统中的各种图或模型结合起来通过验证工作保证图与图之间数据的一致性通过验证工作保证模型能够正确地解决问题如图2-17 所示
输入知识经验
问题描述目标等
使用非正式的工具比
如白板和笔记公告
[通过描绘目标靠近实际工作]
集体讨论 描绘目标
组织目标
详细说明
集成 核实 验证
原型化与测试
系统评价
把非正式工具描绘的
目标组织成正式的图
详细说明图的细节
(反复迭代明确内容)
检查图之间的冲突系
统的有效性和正确性
制造原型和测试原型
评价结果若与目标不
符返回纠正不足之处
[得到满意结果]
[发现不足]
图2.17 实际建模工作的大致流程
最后在实际解决问题的时候模型被实现为各种原型prototype 生成原型时要对生成的原型进行评价以便发现可能潜在的错误遗漏的功能和开发代价过高等不足之处如果发现了上述不足之处那么开发人员还要返回到前期的各个阶段步骤排除这些问题如果问题很严重开发者或许最终要返到刚开始的集体讨论描绘草图的阶段重新建模当然如果问题很小开发者只需改变模型的一部分组织和规格说明注意把图原型化的工作一定要在把多个图结合成原型结构之后原型只是一个很粗浅的东西构建原型仅仅是为了对其进行评价发现其中的不足之处而对原型进一步地开发过程才算得上真正的系统开发过程
2.7 工具的支持
使用建模语言需要相应的工具支持即使人工在白板上画好了模型的草图建模者也需要使用工具因为模型中很多图的维护同步和一致性检查等工作人工做起来几乎是不可能的自从用于产生程序的第一个可视化软件问世以来建模工具又叫CASE 工具一直不很成熟许多CASE 工具几乎和画图工具一样仅提供了建模语言和很少的一致性检查增加了一些方法的知识经过人们不断地改进今天的CASE 工具正在接近图的原始视觉效果比如Rational Rose 工具就是一种比较现代的建模工具但是还有一些工具仍然比较粗糙比如一般软件中很好用的剪切和粘帖功能在这些工具中尚未实现另外每种工具都有属于自己的建模语言或至少有自己的语言定义也限制了这些工具的发展随着统一建模语言UML 的发布工具制造者现在可能会花较多的时间来提高工具质量减少定义新的方法和语言所花费的时间一个现代的CASE 工具应提供下述的功能
画图draw diagrams
CASE 工具中必须提供方便作图和为图着色的功能也必须具有智能能够理解图的目的知道简单的语义和规则这样的特点带来的方便是当建模者不适当地或错误地使用模型元素时工具能自动告警或禁止其操作
积累repository
CASE 工具中必须提供普通的积累功能以便系统能够把收集到的模型信息存储下来如果在某个图中改变了某个类的名称那么这种变化必须及时地反射到使用该类的所有其他图中
导航navigation
CASE 工具应该支持易于在模型元素之间导航的功能也就是使建模者能够容易地从一个图到另一个图地跟踪模型元素或扩充对模型元素的描述
多用户支持
CASE 工具提供该功能使多个用户可以在一个模型上工作但被此之间没有干扰
产生代码generate code
一个高级的CASE 工具一定要有产生代码的能力该功能可以把模型中的所有信息翻译成代码框架把该框架作为实现阶段的基础
逆转reverse
一个高级的CASE 工具一定要有阅读现成代码并依代码产生模型的能力即模型可由代码生成它与产生代码是互逆的两个过程对开发者来说他可以用建模工具或编程二种方法建模
集成integrate
CASE 工具一定要能与其他工具集成即与开发环境比如编辑器编译器和调试器和企业工具比如配置管理和版本控制系统等的集成
覆盖模型的所有抽象层
CASE 工具应该能够容易地从对系统的最上层的抽象描述向下导航至最低的代码层这样若需要获得类中一个具体操作的代码只要在图中单击这个操作的名字即可
模型互换
模型或来自某个模型的个别的图应该能够从一个工具输出然后再输入到另一个工具就像JAVA 代码可在一个工具中产生而后用在另一个工具中一样模型互换功能也应该支持用明确定义的语言描述的模型之间的互换输出输入
2.7.1 绘图支持
CASE 工具应使绘图工作简单而有趣一个高级的绘图工具能够充当CASE 工具经历了一段很长的时间那是因为CASE 工具不仅必须提供优秀的选择放置连接和定义图中元素的机制而且还要帮助建模者着色形成一张正确的图CASE 工具还应该有理解模型元素语义的能力这种能力能够在错误地使用模型元素时发出警告或者提示一个具体的操作与其他操作之间可能存在不一致问题比如在一个模型中若修改某个图后将会引起该图与其他图的冲突这时系统就会自动告警提示建模者的修改可能出现错误CASE 工具也应提供图的版面设计功能比如允许建模者重新排列模型元素而代表消息的线条由工具自动地重新排列使它们彼此不会交叉在很多CAD 系统中这个功能实现得很好建模工具的制造者可以从中借鉴一些经验
<<上一页
1
2
3
4
5
6
7
8
9
10
下一页>>
