uml6.htm

标准建模语言UML及其支持环境

当用户对生成的代码进行修改后,逆向转换机制将用户的修改转换到模型上。否则,将造成模型和代码间的不一致性,使系统的扩充、增删和维护难以进行。<br>
我们认为,如果一个支持环境既有正向变换机制,又有逆向变换机制,就能保持模型和代码的一致性。动态模型的逆向转换机制是研究难点,一般可由建模、析取和抽象三个步骤组成。我们将在正向转换的基础上,建立起模型到代码的映射关系,尝试建立一套约束机制,实现自动的或人工导引的逆向转换机制。目前,国际上对这方面的研究尚不成熟。</p>

<p><br>
五、标准建模语言UML的应用实例</p>

<p><br>
UML是一种建模语言而不是方法,这是因为UML中没有过程的概念,而过程正是方法的一个重要组成部分。UML本身独立于过程,这意味着用户在使用UML进行建模时,可以选用任何适合的过程。过程的选用与软件开发过程的不同因素有关,诸如所开发软件的种类(如实时系统、信息系统和桌面产品)、开发组织的规模(如单人开发、小组开发和团队开发)等。用户将根据不同的需要选用不同的过程。然而,使用UML建模仍然有着大致统一的过程框架,该框架包含了UML建模过程中的共同要素,同时又为用户选用与其所开发的工程相适合的建模技术提供了很大的自由度。</p>

<p><br>
1. UML建模过程高层视图</p>

<p align="center"><img src="../images/uml6-2.jpg" width="472"
height="113"></p>

<p>图2是UML建模过程的一个高层视图。这是一个迭代递增的开发过程。使用此方法,不是在项目结束时一次性提交软件,而是分块逐次开发和提交。构造阶段由多次迭代组成,每一次迭代都包含编码、测试和集成,所得产品应满足项目需求的某一子集,或提交给用户,或纯粹是内部提交。每次迭代都包含了软件生命周期的所有阶段。同时,每次迭代都要增加一些新的功能,解决一些新的问题。<br>
</p>

<p>因此,首先要做的工作是:选择一些功能点,然后完成这些功能;之后再选择别的功能点,如此循环往复。前两个阶段是初始(
Inception)和细化 ( Elaboration) 阶段。在初始阶段,需要考虑项目的效益,并确定项目的范围。这一阶段需要与项目出资方进行讨论。在细化阶段,需要收集更为详细的需求,进行高层分析和设计,并为构造阶段制定计划。运用这种迭代开发过程时,还有一些工作(如β测试、性能调试和用户培训等)要放到最后的移交阶段(Transition)中进行。</p>

<p><br>
事实上,涉及实际建模工作的微过程存在于上述的每次迭代中。迭代式开发是项目成功的重要保证。</p>

<p><br>
2. UML实际建模过程</p>

<p><br>
每次迭代都分为以下几个阶段:<br>
分析阶段　建模的目的是捕捉系统的功能需求,分析、提取所开发系统的&quot;客观世界&quot;领域的类以及描述它们的合作概貌。<br>
设计阶段　建模的目的是通过考虑实现环境,将分析阶段的模型扩展和转化为可行的技术实现方案。<br>
实现阶段　具体工作就是进行编码,同时对已构造的模型作相应的修正。<br>
配置阶段　通过模型描述所开发系统的软硬件配置情况。<br>
测试阶段　使用前几个阶段所构造的模型来指导和协助测试工作。</p>

<p><br>
在系统开发的不同阶段,使用UML为系统建模,可以通过建立不同的模型,从不同的视角,以不同的详略程度对系统进行描述。下面以一个商业管理信息系统的开发过程为例,具体介绍UML建模的实际过程:<br>
(1) 需求<br>
最初版本商业MIS的正文需求规格说明应当由代表系统最终用户的人员提供,内容包括系统基本功能需求和对计算机系统的要求。大致描述如下:<br>
&middot; 它是一个商业支持系统;<br>
&middot; 采购员采购所需的商品;<br>
&middot; 保管员将采购的商品登记入库;<br>
&middot; 调拨员将库存商品调拨到相应的销售部门;<br>
&middot; 销售部门销售商品;<br>
&middot; 统计部门核算商场经营状况;<br>
&middot; 系统能运行于通用的技术环境(如Unix、Windows等)中,具有<br>
良好的图形用户界面<br>
&middot; 系统容易维护,便于功能扩充 。<br>
由于基于UML的系统开发采取增量和迭代方式,商业MIS的初始版本仅需要完成系统的最基本功能(基本业务),而其他功能的实现(如商品移管、电子订货、电子支付、网络销售等)则在以后的版本中完成。</p>

<p><br>
(2) 分析<br>
分析的任务是找出系统的所有需求并加以描述,同时建立模型,以定义系统中的关键领域类,应由系统用户和开发人员合作完成。这一阶段不要拘泥于设计细节和技术方案。</p>

<p><br>
<strong>需求分析<br>
</strong>分析的第一步是定义用例,以描述所开发系统的外部功能需求。用例分析包括阅读和分析需求说明,此时需要与系统的潜在用户进行讨论。用例模型的主要构件是用例、角色和系统边界。用例用于描述每个功能需求,系统边界用于界定系统功能范围,而角色用于描述与系统功能有关的外部实体,它可以是用户,也可以是外部系统。<br>
在本实例中,通过分析,先确认商业MIS中的角色有销售人员、库存人员、采购人员、辅助人员和分析人员。在此基础上,确认用例。商业MIS的用例有订货采购、库存管理、商品销售、统计分析、系统维护(包括增加商品、取消商品、制作标签、价格变更、取消或更新标签)。如图3所示。</p>

<p align="center"><img src="../images/uml6-3.jpg" width="422"
height="290"></p>

<p>除了用用例图描述系统需求外,还可以用文字(或活动图)对每个用例进行需求说明,更具体地描述该用例与角色的交互。例如我们可以描述订货采购用例的需求说明如下:<br>
&middot; 如果是新商品:<br>
a. 新商品登记;<br>
b. 采购进货;<br>
c. 登记入库 。<br>
&middot; 如果商品库存不足:<br>
a. 采购进货;<br>
b. 登记入库。<br>
订货采购需求可以用活动图来描述,如图4所示。由于用例的需求说明直接影响到后续设计阶段对类的操作的定位,因此,用例的需求说明应当尽量全面、准确。</p>

<p align="center"><img src="../images/uml6-4.jpg" width="397"
height="347"></p>

<p>值得说明的是,绝大多数用例可以在系统需求分析阶段确定,但随着系统的进展,可能会发现更多的用例,甚至会发现前面定义的用例存在不够确切或错误的地方,需要重新修改。因此,在整个系统开发过程中,都应当时刻关注用例。</p>

<p><br>
<strong>特定领域分析<br>
</strong>分析阶段的另一项工作是特定领域分析,以列出系统中的特定领域类。我们可以通过阅读规格说明、用例以及寻找系统处理的&quot;概念&quot;来进行特定领域分析,也可以通过用户和领域专家的讨论,以识别出要处理的所有关键类及它们的相互关系。这里的特定领域是指具体的商业领域,而不是整个系统领域。<br>
在本实例中,可以确定商业MIS中的特定领域类为商品、保质商品、非保质商品、物品、销售、订货、库存、厂商,并使用类图来描述系统领域类及其关系。<br>
需要强调的是,这一阶段对特定领域类的描述具有一定的素描性质,也就是说特定领域类的操作和属性不一定与最终实现时的定义一致。因为此时还没有涉及到系统功能的具体实现,不可能准确、完整地定义它们。有一些操作需要在设计阶段细化时才能确定。<br>
此外,为了描述领域类的动态行为,可以使用UML中的任何一种动态图(如顺序图、活动图、合作图、状态图)。本阶段的各动态图都具有素描性质,主要是为了协助对领域类及其相互关系的分析,为下一阶段的具体设计打下基础。<br>
UML建模是很灵活的过程,使用者不必面面俱到地画出各种图。对于每一幅图,只有在必要时(比如能帮助分析、设计、指导编码、加深理解、促进交流等)才需要画出,这样的图对建模才有意义,否则会浪费精力而事倍功半。(未完待续)
<br>
</p>

<p align="center"><a href="../index.htm">Home</a></p>
</body>
</html>