T
taozhiyu
Unregistered / Unconfirmed
GUEST, unregistred user!
Subject: uml五六七
前4期的主要内容包括:
一、标准建模语言uml概述
二、标准建模语言uml的静态建模机制
三、标准建模语言uml的动态建模机制
1. 消息
2. 状态图
3. 顺序图
4. 合作图
(接上期)
5. 活动图(activity diagram)
活动图的应用非常广泛,它既可用来描述操作(类的方法)的行为,也可以描述用例和对象内部
的工作过程。活动图是由状态图变化而来的,它们各自用于不同的目的。活动图依据对象状态
的变化来捕获动作(将要执行的工作或活动)与动作的结果。活动图中一个活动结束后将立即
进入下一个活动(在状态图中状态的变迁可能需要事件的触发)。图1给出了一个活动图的例
子。
活动和转移
一项操作可以描述为一系列相关的活动。活动仅有一个起始点,但可以有多个结束点。活动间
的转移允许带有guard-condition、send-clause和action-expression,其语法与状态图中
定义的相同。一个活动可以顺序地跟在另一个活动之后,这是简单的顺序关系。如果在活动图
中使用一个菱形的判断标志,则可以表达条件关系(见图1),判断标志可以有多个输入和输出
转移,但在活动的运作中仅触发其中的一个输出转移。
活动图对表示并发行为也很有用。在活动图中,使用一个称为同步条的水平粗线可以将一条转
移分为多个并发执行的分支,或将多个转移合为一条转移。此时,只有输入的转移全部有效,
同步条才会触发转移,进而执行后面的活动,如图2所示。
泳道
活动图告诉你发生了什么,但没有告诉你该项活动由谁来完成。在程序设计中,这意味着活动
图没有描述出各个活动由哪个类来完成。泳道解决了这一问题。它将活动图的逻辑描述与顺
序图、合作图的责任描述结合起来。如图2所示,泳道用矩形框来表示,属于某个泳道的活动
放在该矩形框内,将对象名放在矩形框的顶部,表示泳道中的活动由该对象负责。
对象
在活动图中可以出现对象。对象可以作为活动的输入或输出,对象与活动间的输入/输出关系
由虚线箭头来表示。如果仅表示对象受到某一活动的影响,则可用不带箭头的虚线来连接对象
与活动,如图2所示。
信号
如图3所示,在活动图中可以表示信号的发送与接收,分别用发送和接收标志来表示。发送和
接收标志也可与对象相连,用于表示消息的发送者和接收者。
6. 四种图的运用
上面对uml中用于描述系统动态行为的四个图(状态图、顺序图、合作图和活动图)做了简单
地介绍。这四个图均可用于系统的动态建模,但它们各自的侧重点不同,分别用于不同的目的。
下面对如何正确使用这几个图做一简单的总结,在实际的建模过程中要根据具体情况灵活运
用这些建议。
首先,不要对系统中的每个类都画状态图。尽管这样做很完美,但太浪费精力,其实你可能只关
心某些类的行为。正确的做法是:为帮助理解类而画它的状态图。状态图描述跨越多个用例的
单个对象的行为,而不适合描述多个对象间的行为合作。为此,常将状态图与其它技术(如顺序
图、合作图和活动图)组合使用。
顺序图和合作图适合描述单个用例中几个对象的行为。其中顺序图突出对象间交互的顺序,
而合作图的布局方法能更清楚地表示出对象之间静态的连接关系。当行为较为简单时,顺序图
和合作图是最好的选择。但当行为比变复杂时,这两个图将失去其清晰度。因此,如果想显示
跨越多用例或多线程的复杂行为,可考虑使用活动图。另外,顺序图和合作图仅适合描述对象
之间的合作关系,而不适合对行为进行精确定义,如果想描述跨越多个用例的单个对象的行为,
应当使用状态图。
四、标准建模语言uml支持环境
标准建模语言uml定义良好、易于表达、功能强大,不仅支持面向对象的分析与设计,而且支
持从需求分析开始的软件开发的全过程。但如何恰当地将这种可视化图形建模技术用于解决
软件开发所面临的问题,如何研制和开发支持uml的建模过程及其支持环境,仍是目前该领域
的热点问题。
目前,在基于uml的开发方法和环境方面,国际上已经进行了一些研究和实际开发工作。
rational 公司正致力于它称之为objectory过程的研究,并试图将其原有支持omt的工具作
进一步扩充,以期支持uml建模。国内对uml支持环境的研制开发工作尚处于起步阶段。
这里从当前对软件开发过程的需求及其动向出发,提出了uml柔性软件开发过程的概念,并设
计了相应的uml集成化支持环境的组成框架。
1. 过程工程的基本要点
任何语言的支持环境都是为了更好地开发计算机应用系统,而任何计算机应用系统又都是为
一定的企事业的目标服务的。因此计算机应用系统及其支持环境的研制与开发,必须在企事业
过程工程理论的指导下进行。下面根据我们近十年来从事过程工程理论研究与正反两方面的
实际经验,扼要介绍过程工程理论和过程工程环境的基本要点。
(1) 任何企事业都可以也都应该从过程、资源、机构、行为和信息等五方面来描述。其中过
程是指该企事业所进行的活动及其活动间的关系,它有一个包含规划、设计、建造和应用等四
个阶段呈螺旋特征的生命周期。刻划一个企事业模型,首先必须研究这五个方面模型的定量描
述技术及其相互关系的约束理论,并研究其描述技术及约束理论在四个不同阶段中的演变情
况,建立系统动力学模型,为采用模拟技术解决上述五个方面模型的综合集成与整体优化奠定
理论基础。
(2) 任何企事业中的过程都可划分为纵向过程与横向过程两类。纵向过程是以产品工程技术
为核心的逐步发展的硬技术群,横向过程是以产品和过程的管理技术为主体的服务于纵向过
程的软技术群。因此要刻划一个企事业过程,还必须研究纵向过程与横向过程的定性模型与定
量度量技术,研究这两类过程的相互关系,以建立产品开发和管理过程相结合的集成化综合模
型,为采用模拟技术研究硬技术群与软技术群的相互之间的量化关系奠定理论基础。
(3) 在瞬息万变的信息化社会中,由于客观环境(系统的外部参数)和主观实体(系统的内部结
构及状态)均具有动态的性质,系统模型的结构、状态及其计算机支持环境也应随之而变化。
为此,要研究面向对象技术在过程工程中的应用技术,把软件工程、过程工程和企事业工程结
合起来,为建立自适应的过程工程支持环境奠定理论基础。我们不妨把软件工程、过程工程、
企事业工程三者结合起来进行综合考察的工程技术称之为聚合工程,把自适应的计算机支持
环境称之为柔性信息系统。
(4) 过程的规模可大可小,过程的持续时间可长可短。因此要研究既能支持过程的横向划块
(将过程规模较大的系统划分成若干个规模较小的子系统)、又能支持过程的纵向分段(将持续
时间较长的过程划分成几个持续时间较短的子过程)的分割与综合技术,研究资源的动态调度
技术以及模型的局部实例化与局部模拟技术,为采用模拟技术研究大范围、长周期的复杂动力
学系统奠定技术基础。
由以上理论可知,任何语言的支持环境必须满足这些基本的技术设施,这就是我们研制与开发
标准建模语言uml支持环境的基本出发点。在这些基本点中,特别值得注意的是前三条,即聚
合工程和柔性信息系统的概念。
2. uml柔性软件开发过程及其支持环境
(1) uml柔性软件开发过程
软件系统的规模越来越大,复杂程度不断提高,传统的软件开发模式越来越难以满足需求。新
的产品开发周期已不再是从需求定义、软件设计、实现和交付的一次性过程,迭代式增量开发
方式已得到了广泛采用。除了传统概念上的时间、质量和花费三个主要要求外,产品支持系统
的"柔性"成为更加重要的核心需求。因此我们将新的软件开发模式归结为图4所示的迭代式
开发和图5所示的柔性软件开发模型。
所谓柔性软件开发是指软件开发过程应在需求工程的牵引下,首先建立系统的顶层模型,并对
其进行模拟、分析和调整。次之,将顶层模型自顶向下地进行分解,建立该系统各个子系统的
模型,对这些子模型进行模拟、分析和调整。然后将子模型的模拟结果,逐次代入上层,再对该
上层模型进一步进行模拟、分析和调整,如有不适,则进行修改。因此整个建模过程是一个"
自顶向下建模,由底向上修改"的反复迭代的过程。简言之,柔性软件开发过程是一个在需求牵
引下,自顶向下分层细化地建模,然后按照"t型技术",通过对模型的虚拟执行,由底向上地逐
层上移修改,直至各层的模拟结果都满足需求为止。
代码的生成建立在模型正确性的基础上,同时考虑到对需求修改的灵活性和快速响应能力,实
施能够反馈修改的"闭环开发"。即不仅能支持从模型到代码的自动生成,将新的模型转换为代
码,还能支持从代码到模型的逆向变换,将原有的代码转化成模型,进行再次分析、修改和调整
以及新一轮的开发,从而为增量式开发提供支持。这样不仅能做到分阶段提交产品,也提高了
对用户需求变化的响应速度和应变能力,以满足用户不断变化的新的需求。
(2) uml支持环境的基本需求
根据上述理论以及我们十五年来研制与开发集成化软件工程环境正反两方面的经验,一个完
善的集成化过程工程环境在功能上应满足以下基本需求:
·应能支持开发完备的过程模型(即应能从过程、资源、机构、行为和信息等五个侧面来描述
企事业过程)与系统模型(即应能从过程、行为、信息和结构等四个侧面来描述一个系统)。
·在这个环境支持下建立的模型应是一个可执行的过程(系统)模型,即应能支持模型的虚拟执
行(模拟)和实际运作,从而可在不同的层次上对模型进行分析和优化。
·过程(系统)模型应采用可视化的图符与正文描述相结合的表达方式,其可视化模型图的结构
应能客观、自然地反映出企事业各部门间的通信和同步关系。
·应能支持建模人员或管理人员按照企事业(系统)内外部的约束条件对模型的执行进行灵活
的控制,从而实现开发过程与管理过程的交叉。
·应能支持从模型自动生成可在internet上运行且支持多平台共享与多数据库存取的应用系
统,从而实现对第三代过程工程自动化的有力支持。
·还应能支持对各类构件库的灵活管理,支持基于构件的程序设计方法,实现过程构件、需求
描述、系统结构与软件构件的复用和组装。
uml集成化支持环境应对集成化过程工程环境和集成化系统工程环境提供强有力的技术支
持。一方面在功能与接口上三者必须无缝连接,另一方面在风格上三者必须协调一致。在分工
上,过程工程环境的目标是优化过程,系统工程环境的目标是自动产生优化了的计算机应用系
统,uml支持环境的目标是为建成柔性的计算机应用系统提供技术支持。(未完待续)
前4期的主要内容包括:
一、标准建模语言uml概述
二、标准建模语言uml的静态建模机制
三、标准建模语言uml的动态建模机制
1. 消息
2. 状态图
3. 顺序图
4. 合作图
(接上期)
5. 活动图(activity diagram)
活动图的应用非常广泛,它既可用来描述操作(类的方法)的行为,也可以描述用例和对象内部
的工作过程。活动图是由状态图变化而来的,它们各自用于不同的目的。活动图依据对象状态
的变化来捕获动作(将要执行的工作或活动)与动作的结果。活动图中一个活动结束后将立即
进入下一个活动(在状态图中状态的变迁可能需要事件的触发)。图1给出了一个活动图的例
子。
活动和转移
一项操作可以描述为一系列相关的活动。活动仅有一个起始点,但可以有多个结束点。活动间
的转移允许带有guard-condition、send-clause和action-expression,其语法与状态图中
定义的相同。一个活动可以顺序地跟在另一个活动之后,这是简单的顺序关系。如果在活动图
中使用一个菱形的判断标志,则可以表达条件关系(见图1),判断标志可以有多个输入和输出
转移,但在活动的运作中仅触发其中的一个输出转移。
活动图对表示并发行为也很有用。在活动图中,使用一个称为同步条的水平粗线可以将一条转
移分为多个并发执行的分支,或将多个转移合为一条转移。此时,只有输入的转移全部有效,
同步条才会触发转移,进而执行后面的活动,如图2所示。
泳道
活动图告诉你发生了什么,但没有告诉你该项活动由谁来完成。在程序设计中,这意味着活动
图没有描述出各个活动由哪个类来完成。泳道解决了这一问题。它将活动图的逻辑描述与顺
序图、合作图的责任描述结合起来。如图2所示,泳道用矩形框来表示,属于某个泳道的活动
放在该矩形框内,将对象名放在矩形框的顶部,表示泳道中的活动由该对象负责。
对象
在活动图中可以出现对象。对象可以作为活动的输入或输出,对象与活动间的输入/输出关系
由虚线箭头来表示。如果仅表示对象受到某一活动的影响,则可用不带箭头的虚线来连接对象
与活动,如图2所示。
信号
如图3所示,在活动图中可以表示信号的发送与接收,分别用发送和接收标志来表示。发送和
接收标志也可与对象相连,用于表示消息的发送者和接收者。
6. 四种图的运用
上面对uml中用于描述系统动态行为的四个图(状态图、顺序图、合作图和活动图)做了简单
地介绍。这四个图均可用于系统的动态建模,但它们各自的侧重点不同,分别用于不同的目的。
下面对如何正确使用这几个图做一简单的总结,在实际的建模过程中要根据具体情况灵活运
用这些建议。
首先,不要对系统中的每个类都画状态图。尽管这样做很完美,但太浪费精力,其实你可能只关
心某些类的行为。正确的做法是:为帮助理解类而画它的状态图。状态图描述跨越多个用例的
单个对象的行为,而不适合描述多个对象间的行为合作。为此,常将状态图与其它技术(如顺序
图、合作图和活动图)组合使用。
顺序图和合作图适合描述单个用例中几个对象的行为。其中顺序图突出对象间交互的顺序,
而合作图的布局方法能更清楚地表示出对象之间静态的连接关系。当行为较为简单时,顺序图
和合作图是最好的选择。但当行为比变复杂时,这两个图将失去其清晰度。因此,如果想显示
跨越多用例或多线程的复杂行为,可考虑使用活动图。另外,顺序图和合作图仅适合描述对象
之间的合作关系,而不适合对行为进行精确定义,如果想描述跨越多个用例的单个对象的行为,
应当使用状态图。
四、标准建模语言uml支持环境
标准建模语言uml定义良好、易于表达、功能强大,不仅支持面向对象的分析与设计,而且支
持从需求分析开始的软件开发的全过程。但如何恰当地将这种可视化图形建模技术用于解决
软件开发所面临的问题,如何研制和开发支持uml的建模过程及其支持环境,仍是目前该领域
的热点问题。
目前,在基于uml的开发方法和环境方面,国际上已经进行了一些研究和实际开发工作。
rational 公司正致力于它称之为objectory过程的研究,并试图将其原有支持omt的工具作
进一步扩充,以期支持uml建模。国内对uml支持环境的研制开发工作尚处于起步阶段。
这里从当前对软件开发过程的需求及其动向出发,提出了uml柔性软件开发过程的概念,并设
计了相应的uml集成化支持环境的组成框架。
1. 过程工程的基本要点
任何语言的支持环境都是为了更好地开发计算机应用系统,而任何计算机应用系统又都是为
一定的企事业的目标服务的。因此计算机应用系统及其支持环境的研制与开发,必须在企事业
过程工程理论的指导下进行。下面根据我们近十年来从事过程工程理论研究与正反两方面的
实际经验,扼要介绍过程工程理论和过程工程环境的基本要点。
(1) 任何企事业都可以也都应该从过程、资源、机构、行为和信息等五方面来描述。其中过
程是指该企事业所进行的活动及其活动间的关系,它有一个包含规划、设计、建造和应用等四
个阶段呈螺旋特征的生命周期。刻划一个企事业模型,首先必须研究这五个方面模型的定量描
述技术及其相互关系的约束理论,并研究其描述技术及约束理论在四个不同阶段中的演变情
况,建立系统动力学模型,为采用模拟技术解决上述五个方面模型的综合集成与整体优化奠定
理论基础。
(2) 任何企事业中的过程都可划分为纵向过程与横向过程两类。纵向过程是以产品工程技术
为核心的逐步发展的硬技术群,横向过程是以产品和过程的管理技术为主体的服务于纵向过
程的软技术群。因此要刻划一个企事业过程,还必须研究纵向过程与横向过程的定性模型与定
量度量技术,研究这两类过程的相互关系,以建立产品开发和管理过程相结合的集成化综合模
型,为采用模拟技术研究硬技术群与软技术群的相互之间的量化关系奠定理论基础。
(3) 在瞬息万变的信息化社会中,由于客观环境(系统的外部参数)和主观实体(系统的内部结
构及状态)均具有动态的性质,系统模型的结构、状态及其计算机支持环境也应随之而变化。
为此,要研究面向对象技术在过程工程中的应用技术,把软件工程、过程工程和企事业工程结
合起来,为建立自适应的过程工程支持环境奠定理论基础。我们不妨把软件工程、过程工程、
企事业工程三者结合起来进行综合考察的工程技术称之为聚合工程,把自适应的计算机支持
环境称之为柔性信息系统。
(4) 过程的规模可大可小,过程的持续时间可长可短。因此要研究既能支持过程的横向划块
(将过程规模较大的系统划分成若干个规模较小的子系统)、又能支持过程的纵向分段(将持续
时间较长的过程划分成几个持续时间较短的子过程)的分割与综合技术,研究资源的动态调度
技术以及模型的局部实例化与局部模拟技术,为采用模拟技术研究大范围、长周期的复杂动力
学系统奠定技术基础。
由以上理论可知,任何语言的支持环境必须满足这些基本的技术设施,这就是我们研制与开发
标准建模语言uml支持环境的基本出发点。在这些基本点中,特别值得注意的是前三条,即聚
合工程和柔性信息系统的概念。
2. uml柔性软件开发过程及其支持环境
(1) uml柔性软件开发过程
软件系统的规模越来越大,复杂程度不断提高,传统的软件开发模式越来越难以满足需求。新
的产品开发周期已不再是从需求定义、软件设计、实现和交付的一次性过程,迭代式增量开发
方式已得到了广泛采用。除了传统概念上的时间、质量和花费三个主要要求外,产品支持系统
的"柔性"成为更加重要的核心需求。因此我们将新的软件开发模式归结为图4所示的迭代式
开发和图5所示的柔性软件开发模型。
所谓柔性软件开发是指软件开发过程应在需求工程的牵引下,首先建立系统的顶层模型,并对
其进行模拟、分析和调整。次之,将顶层模型自顶向下地进行分解,建立该系统各个子系统的
模型,对这些子模型进行模拟、分析和调整。然后将子模型的模拟结果,逐次代入上层,再对该
上层模型进一步进行模拟、分析和调整,如有不适,则进行修改。因此整个建模过程是一个"
自顶向下建模,由底向上修改"的反复迭代的过程。简言之,柔性软件开发过程是一个在需求牵
引下,自顶向下分层细化地建模,然后按照"t型技术",通过对模型的虚拟执行,由底向上地逐
层上移修改,直至各层的模拟结果都满足需求为止。
代码的生成建立在模型正确性的基础上,同时考虑到对需求修改的灵活性和快速响应能力,实
施能够反馈修改的"闭环开发"。即不仅能支持从模型到代码的自动生成,将新的模型转换为代
码,还能支持从代码到模型的逆向变换,将原有的代码转化成模型,进行再次分析、修改和调整
以及新一轮的开发,从而为增量式开发提供支持。这样不仅能做到分阶段提交产品,也提高了
对用户需求变化的响应速度和应变能力,以满足用户不断变化的新的需求。
(2) uml支持环境的基本需求
根据上述理论以及我们十五年来研制与开发集成化软件工程环境正反两方面的经验,一个完
善的集成化过程工程环境在功能上应满足以下基本需求:
·应能支持开发完备的过程模型(即应能从过程、资源、机构、行为和信息等五个侧面来描述
企事业过程)与系统模型(即应能从过程、行为、信息和结构等四个侧面来描述一个系统)。
·在这个环境支持下建立的模型应是一个可执行的过程(系统)模型,即应能支持模型的虚拟执
行(模拟)和实际运作,从而可在不同的层次上对模型进行分析和优化。
·过程(系统)模型应采用可视化的图符与正文描述相结合的表达方式,其可视化模型图的结构
应能客观、自然地反映出企事业各部门间的通信和同步关系。
·应能支持建模人员或管理人员按照企事业(系统)内外部的约束条件对模型的执行进行灵活
的控制,从而实现开发过程与管理过程的交叉。
·应能支持从模型自动生成可在internet上运行且支持多平台共享与多数据库存取的应用系
统,从而实现对第三代过程工程自动化的有力支持。
·还应能支持对各类构件库的灵活管理,支持基于构件的程序设计方法,实现过程构件、需求
描述、系统结构与软件构件的复用和组装。
uml集成化支持环境应对集成化过程工程环境和集成化系统工程环境提供强有力的技术支
持。一方面在功能与接口上三者必须无缝连接,另一方面在风格上三者必须协调一致。在分工
上,过程工程环境的目标是优化过程,系统工程环境的目标是自动产生优化了的计算机应用系
统,uml支持环境的目标是为建成柔性的计算机应用系统提供技术支持。(未完待续)
]