汉语解释为统一建模语言
意思是说:用图表的方式将要设计的软件问题建模,将问题分解化,适合于其他开发者阅读
明白吗?
统一建模语言(Unified Modeling Language)是一种用于描述、构造软件系统以及商业建模的语言,综合了在大型、复杂系统的建模领域得到认可的优秀的软件工程方法。UML是大多数公司采用的标准,是ANSI和OMG等部门采用的标准。
1993年Rational公司的Booch、Rumbaugh、Jacobson开始设计UML方法,1995年后期,正式推出0.8版的Unified Method。1996年,改进的Unified Method正式更名为UML(Unified Modeling Language)。1997年UMLl.0被提交给对象技术组织OTG(Object Technology Organization),最后,1997年11月14日,OMG将UML1.作为行业标准。UML结合了Booch、OMT和Jacobson方法,统一了符号体系,并从其它的方法和软件工程实践中吸收了许多经过实际检验的概念和技术,UML是Grady Booch、Dr. James Rumbaugh、Ivar Jacobson、Rebecca Wirfs-Brock、Peter Yourdon和许多其他人员集体智慧的结晶。
UML的产生有三方面的原因:首先,不同的面向对象方法有着许多相似之处,通过这项工作,消除可能会给使用者造成混淆的不必要的差异是非常有意义的;其次,语义和表示法的统一,可以稳定面向对象技术的市场,使工程开发可以采用一门成熟的建模语言,CASE工具的设计者也可以集中精力设计出更优秀的系统;第三,这种统一能使现有的方法继续向前发展,积累已有的经验,解决以前没有解决好的问题。
UML为软件系统建模提供了以下四个方面的支持:
· 使用事件模型 (use case):定义系统的使用事件(use case)、角色(actor)及角色与事件之间的交互行为(association)。
· 类和对象模型:定义类、对象及相互之间的关系。
· 组件模型:组件是组成应用程序的可执行单元,类被分配到组件中,以提供可重复使用的应用程序结构部件。组件为即插即用的应用程序结构奠定了基础。UML对可重用性的支持,在设计的前期体现在支持可重复使用的类和结构,后期则体现在组件装配。
· 分布处理模型:将软件系统映射到分布处理结构中。UML能够描述网络拓扑结构的节点,这些节点相互的连接方式以及软件系统在网络中的分布情况。
利用UML框图可以开发几种不同的可视框图,表示系统的不同方面。这些框图主要有:
· Use Case框图:显示使用案例Case(系统功能)和角色(表示提供或接收系统信息的用户和系统)之间的交互。
· Sequence框图。显示使用案例的功能流程。
· Collaboration框图:显示对象间为完成某个系统功能而进行的交互。
· C1ass框图:显示系统中类与类之间的交互。
· State Transition框图:Class框图显示系统中类的静态图形,而State Transition框图显示动态图形,即系统状态分析。
· Component框图:模型的物理视图,显示系统中的软件组件以及它们之间的相互关系。
· Deployment框图:显示网络的物理布局和各种组件的位置。
如何使用IBM Rational Software Architect实现模型驱动的软件开发
模型驱动架构(MDA)是OMG提出的新的方法学, 是一种新的系统开发方法,它强调整个系统开发过程由对软件系统的建模行为驱动,完成系统需求分析、架构设计、构建、测试、部署和运维工作。与传统的UML 模型相比,MDA能够创建出机器可读和高度抽象的模型,这种模型通过转换(Transformation)技术可自动转换为代码、测试脚本、数据库定义以 及各种平台部署描述。从此,建模语言不仅仅是分析设计语言,更可用作为一种高级编程语言。 MDA通过抽象层次的不同,定义了计算独立模型(CIM)、平***立模型(PIM)和平台相关模型(PSM)。计算独立模型类似于我们常说的业务模型和用 例模型,是一个抽象层次较高、独立于任何实现技术的系统模型,它着眼于操作环境中的系统以及系统需求的描述,而不关心系统本身的结构和功能实现细节;平台 独立模型类似于系统分析模型,它处于中间抽象层次,关注系统的整个架构实现,但却忽略掉与平台相关的部分。平***立模型可以转换成多个平台相关模型;平台 相关模型则与设计模型相像,它把业务独立模型与具体使用平台的细节相结合,包含了具体平台的特定实现技术。软件开发过程中架构师会跟据系统架构的质量要 求,选择一种或几种平台技术具体实现系统。
图1.1、MDA的模型及其转换技术
不 同模型间可以通过模型转换技术(Model Transformation)实现相互转化,例如使用模型转换技术,我们可以将计算独立模型(CIM)转化为平***立模型(PIM),平***立模型 (PIM)转化为平台相关模型(PSM)。由此可见,模型转化技术是实现MDA的关键。模型转换技术一般包括标记(Markings)和映射 (Mapping),映射包含了由一种模型向另一种模型转化的规约说明,而标记则用来在源模型中加入额外的信息,用来在转换时告诉映射如何将源模型中的特 定模型元素映射到目标模型。
通过MDA技术的使用,可以有效解决传统软件开发过程中的生产效率问题、系统移植问题、互操作问题以及文档和系统后期维护问题,因此它一出现就受到业界的广泛关注,并且越来越多的工具厂商对其提供支持,我们坚信:它的广泛应用只是时间问题。
回页首
2 在RSA中实现MDA
2.1 RSA概述
IBM Rational Software Architect(RSA)是一套设计与开发工具,它构建在开放的、可扩展的Eclipse3.0平台之上,实现了多项行业最新标准,提供了灵活的插件 扩展机制。借助UML2.0技术,它实现了模型驱动的软件开发模式,可以帮助开发团队创建更加强壮的软件架构。同时,RSA作为IBM Rational业务驱动软件开发平台的核心构件,提供了与需求管理工具、测试工具、配置和变更管理工具和项目管理工具的完美集成 ,从而真正实现了企业内部的核心软件开发流程、开发平台和软件生产线。
2.2 使用RSA实现MDA中的模型转换
IBM 在RSA中缺省提供了UML到Java、UML到C++、UML到EJB的模型转化实现,其整个实现架构基于Eclipse 3.0和Eclipse Model Framework(EMF)、UML2、Graphical Editing Framework(GEF)和插件开发环境(PDE),为模型驱动软件开发(MDA)的模型转换方面提供了四个方面的工具支持:
图2.1、RSA对MDA及其转换技术的支持架构
1) 转换服务(Transformation Service):支持转换的交换和发现功能,为其它转换工具支持提供基础。
2) 转换引擎(Transformation Engine):为层次化的转换源提供遍历引擎,尤其对UML模型有较好支持
3) 转换应用的GUI界面支持:使用户能够浏览、查找并应用各种转换。
4) 制作转换的GUI界面支持:为转化制作中的创建、打包和维护转换的各种任务,提供很多自动化支持;
在RSA中,MDA的模型转换以插件的形式存在。RSA提供了向导(Wizard)功能,指导用户完成模型转换框架插件项目的创建过程,下面举例说明具体的MDA的模型转换开发过程:
1) 新建插件项目:在RSA中选择"File-> New ->Project…"新建插件项目,选择"带转换的插件"模板,它是RSA为构建新的转换提供的实现机制。
UML的产生背景及用处
UML是大多数公司采用的标准,是ANSI和OMG等部门采用的标准。
1993年Rational公司的Booch、Rumbaugh、Jacobson开始设计UML方法,1995年后期,正式推出0.8版的Unified Method。1996年,改进的Unified Method正式更名为UML(Unified Modeling Language)。1997年UMLl.0被提交给对象技术组织OTG(Object Technology Organization),最后,1997年11月14日,OMG将UML1.作为行业标准。UML结合了Booch、OMT和Jacobson方法,统一了符号体系,并从其它的方法和软件工程实践中吸收了许多经过实际检验的概念和技术,UML是Grady Booch、Dr. James Rumbaugh、Ivar Jacobson、Rebecca Wirfs-Brock、Peter Yourdon和许多其他人员集体智慧的结晶。
UML的产生有三方面的原因:首先,不同的面向对象方法有着许多相似之处,通过这项工作,消除可能会给使用者造成混淆的不必要的差异是非常有意义的;其次,语义和表示法的统一,可以稳定面向对象技术的市场,使工程开发可以采用一门成熟的建模语言,CASE工具的设计者也可以集中精力设计出更优秀的系统;第三,这种统一能使现有的方法继续向前发展,积累已有的经验,解决以前没有解决好的问题。
UML为软件系统建模提供了以下四个方面的支持:
• 使用事件模型 (use case):定义系统的使用事件(use case)、角色(actor)及角色与事件之间的交互行为(association)。
• 类和对象模型:定义类、对象及相互之间的关系。
• 组件模型:组件是组成应用程序的可执行单元,类被分配到组件中,以提供可重复使用的应用程序结构部件。组件为即插即用的应用程序结构奠定了基础。UML对可重用性的支持,在设计的前期体现在支持可重复使用的类和结构,后期则体现在组件装配。
• 分布处理模型:将软件系统映射到分布处理结构中。UML能够描述网络拓扑结构的节点,这些节点相互的连接方式以及软件系统在网络中的分布情况。
利用UML框图可以开发几种不同的可视框图,表示系统的不同方面。这些框图主要有:
• Use Case框图:显示使用案例Case(系统功能)和角色(表示提供或接收系统信息的用户和系统)之间的交互。
• Sequence框图。显示使用案例的功能流程。
• Collaboration框图:显示对象间为完成某个系统功能而进行的交互。
• C1ass框图:显示系统中类与类之间的交互。
• State Transition框图:Class框图显示系统中类的静态图形,而State Transition框图显示动态图形,即系统状态分析。
• Component框图:模型的物理视图,显示系统中的软件组件以及它们之间的相互关系。
• Deployment框图:显示网络的物理布局和各种组件的位置。
面向对象的分析与设计(OOA&D)方法的发展在80年代末至90年代中出现了一个高潮,UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法,而且对其作了进一步的发展,并最终统一为大众所接受的标准建模语言。
简述类UML图中的重复度与ER模型中实体的基数的区别
5.简述类图中的重复度与ER图中实体的基数的区别?
重复度和基数是两个相反的概念。实体基数是指与一个实体有联系的另一端实体数目的最小、最大值,基数应该写在这一端实体的边上。而重复度是指参与关联的这一端对象数目的最小、最大值,重复度应写在这一端类的边上
一定UML吗?——看看结构化设计实例
背景:自从OOA、OOD被业界推崇以来,运用UML进行需求分析、架构设计几乎成为圣经,似乎使用迭代和UML就先进了、OO了,用传统的方法就是落后了、非OO了。事实上无论运用什么工具或方法,只要能够充分反映软件内在的本质就可以了。传统的软件工程中主要有如下建模工具:IPO模型、万诺模型、ER模型、JACKSON模型、DFD模型、程序流程图等,与之对应的详细设计方法主要是结构化设计法。在几年的MIS项目实践中我对传统软件工程领域中较为推崇的有:ER模型、Petri网、DFD模型、JACKSON模型和程序流程图。ER模型主要运用于领域模型设计、Petri网运用于工作流建模、DFD模型主要用于数据动态关联建模、Jackson模型主要运用于非ER环境的复杂数据结构建模及其相关算法(变换)建模、程序流程图用于对重要算法或处理过程进行说明。在我的项目中,主要运用的工具仍然是UML,但是在上述的一些环节中,我和我的团队仍然会运用传统软件工程领域中的一些建模方法,特别是现在流程重构需求较多以及大量的快速开发工具被运用的情况下,传统的东西似乎用得越来越多。我的实际经验表明,运用好传统的软件工程方法,会比一味的追求OOA、OOD更有效果。以下就以开发中的一个实例进行说明,限于商业考虑,只能在此将一些有代表性的文档拿出来讨论,希望大家能一块来讨论。一、用户业务流程说明客户是一个较大的机构,位于市区,在当地区县、乡镇均设有下级部门,为了提高企业库存周转率、防止库存积压导致现金占用的现象,该企业实行预算控制、集中采购。未上信息系统以前,区县、乡镇到市区领用物资的时候需要经历多道审批手续,时间长、管理成本大、数据滞后混乱。通过和客户认真沟通,并结合各职能部门的职责,对企业内部相关流程进行了重构、优化,并对一些机构的职责进行了微调。下图给出的就是整理后“按照物资进行领料”的工作流图,该图截取自JBPM的设计器,本质上一个Petri网。由于JBPM未能够将泳道在图上可视化表达,因此又让美工通过PS加上了泳道。 二、ER模型在实际为客户解决问题的过程中,我们分析并设计出了一个较为庞大的领域模型,主要的工具是PowerDesign,由于此处给出的实例是大家常见的一个需求情况,因此不给出数据库设计的实例。 三、流程中关键环节的数据处理过程1、当物料分发系统中的ERP领料单处于编辑状态时,要将ERP系统中的对应的ERP单号填写到该单据中,且ERP单号不能重复。当ERP领料单编辑完成后,可以提交ERP领料单到上级部门进行审核。如果觉得该单据制的不对,也不能通过修改进行调整过来,可以直接将该单据放弃。提交ERP单据和放弃ERP单据的数据流向入下图所示。 2、归口部门审核,有同意和拒绝两种情况。 3、预算部门的审核,有同意和拒绝两种情况。 4、ERP的审核,有同意和拒绝两种情况。 5、入库部门的审核,有同意和拒绝两种情况。 四、开发过程说明1、数据库使用PowerDesigner 12.1 进行设计,首先进行概念模型建模(ER),通过概念模型生成物理模型,通过物理模型生成Oracle建库脚本;2、通过概念模型生成OO模型,然后编辑OO模型与物理模型的映射关系,生成POJO类和基于Hibernate的DAO;3、用JUNIT对自动生成的DAO进行全面测试,未发现问题;4、分析业务流程后,建立JBPM业务协作模型,并依据分析出来的DFD编写JBPM各节点的Action Handler,发布并部署JBPM;5、使用BSTEK,快速生成开发界面,软件界面大致分为三种(1)简单的CRUD,由BSTEK快速生成,基本上不编写代码;(2)与工作流程中各交互页面在BSTEK上设计,用户提交后,将用户表单的数据直接映射到JBPM的任务上下文中,并触发流程事件,由ActionHandler来完成后续的数据具体操作;(3)其他的一些传统页面。
建立一个系统的SOA模型,如果用4+1视图的的方式建立服务模型,每一个视图应该用哪些UML图表示?
逻辑视图(Logical View)可以用ERD,数据流图等等。
过程视图(Process View)可以用时序图,流程图。
物理视图(Physical View)基本跟UML没关系。
开发视图(Development View)里可以用模块图之类的静态图表示。
第五个视图用用例图。
软件体系结构建模中,4+1视图模型(逻辑视图、开发视图、进程视图、物理视图、场景)分别对应UML中的哪个图
1、场景视图 :静态方面用 用例图 表现,动态方面用活动图、状态图、交互图表现。
2、逻辑视图:包含了类、接口、协作,静态方面用 类图和对象图表现,动态方面用活动图、状态图、交互图表现。
3、开发视图:(Development View),描述了在开发环境中软件的静态组织结构。静态方面用 组件图 表示。
4、进程视图:侧重系统的运行特性关注非功能性的需求性能可用性。服务于系统集成人员方便后续性能测试。强调并发性、分布性、集成性、鲁棒性容错、可扩充性、吞吐量等。和逻辑实体类似,可用类图(扩展)、活动图、交互图、状态图表现。
5、物理视图 : 主要描述硬件配置。服务于系统工程人员解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上也要考虑系统性能、规模、可靠性等,静态方面用 部署图 表现,动态方面用活动图、状态图、交互图表现。
UML十大模型图的内容是什么?它们是如何进行分类的?
用例图:描述系统功能;
类图: 描述系统的静态结构;
对象图 :描述系统在某个时刻的静态结构;
包图:
时序图:按时间爱你顺序描述系统元素间的交互;
协作图:按照时间和空间顺寻描述系统元素间的交互和它们之间的关系;
状态图:描述了系统元素的状态条件和响应;
活动图:描述了系统元素的活动;
组件图:描述了实现系统的元素的组织;
配置图:描述了环境元素的配置,并把实现系统的元素映射到配置上。
参考资料:UML基础与ROSE建模案例(第二版)
转载请注明出处51数据库 » 软件公司UML模型映射 什么是UML