下载文档原格式
uml基础案例与应用UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言。
它提供了一种统一的、标准化的表示方法，可以帮助开发人员更清晰、更准确地描述和设计软件系统。
下面列举了十个基于UML的案例与应用：1. 用例图（Use Case Diagram）：用例图是UML中最常用的图之一，用于描述系统的功能和行为。
它通过显示系统与外部实体之间的交互来帮助开发人员理解系统的需求和功能。
2. 类图（Class Diagram）：类图是描述系统中类和类之间关系的图。
它展示了系统中的类、类的属性和方法，以及类之间的关系，如继承、关联、聚合等。
类图可以帮助开发人员理解系统的结构和组织。
3. 对象图（Object Diagram）：对象图是类图的实例化，用于描述系统中对象之间的关系。
它展示了系统中的对象、对象的属性和方法，以及对象之间的关系。
对象图可以帮助开发人员理解系统的运行时状态。
4. 序列图（Sequence Diagram）：序列图是描述系统中对象之间交互的图。
它展示了对象之间的消息传递顺序，以及消息的参数和返回值。
序列图可以帮助开发人员理解系统的动态行为和时序关系。
5. 状态图（State Diagram）：状态图是描述系统中对象状态和状态转换的图。
它展示了对象在不同状态之间的转换条件和动作。
状态图可以帮助开发人员理解系统的状态变化和行为逻辑。
6. 活动图（Activity Diagram）：活动图是描述系统中活动流程和业务流程的图。
它展示了活动之间的控制流和数据流，以及活动的并发和同步。
活动图可以帮助开发人员理解系统的工作流程和业务逻辑。
7. 组件图（Component Diagram）：组件图是描述系统中组件和组件之间关系的图。
它展示了系统中的组件、组件的接口和依赖关系。
组件图可以帮助开发人员理解系统的组件结构和模块化设计。
8. 部署图（Deployment Diagram）：部署图是描述系统中硬件和软件部署的图。
UML 建模设计航空订票系统姓名：卫飞班级：1528学号：201515614375一、背景1.1背景概述随着知识经济的到来，人类已经逐步进入信息化社会，信息增长的速度越来越快，人们希望利用先进的管理理论方法手段来得到并处理越来越多的信息，以提高工作效率和管理水平。
由于信息资源对人们生活的重要性，不断提高信息的收集，传输，加以利用等活动，日益成为人们社会生活的重要组成部分。
网上机票预订管理系统的产生和发展正好满足人们的这种需求1.2 主要组成及功能1、新用户注册，新用户可以注册，注册时输入用户名可以查询用户可不可用，可用就可以注册，注册时可以判断用户输入的密码和验证密码是否相同，相同才给以注册，如果满意可以点注册，注册成功后用户可以选择不用在回到登陆界面，可以直接陆到用户主界面，以后就可以用这个用户登录了，如果不满意，点取消，所有信息清空，重新输入。
2、验证登陆名密码，正确进入主菜单，根据登录时所选的登录方式（客户、管理员）的不同分别对用户设定不同的访问权限（如果是输入的客户用户名和密码正确，选择以客户方式登陆则主界面里面的管理员界面不能用，如果输入的是管理员的相应用户密码正确，以管理员的方式登陆则管理员界面可用）不正确则清空登录框，最多可以输入三次，三次不正确系统会自动关闭3.我的航班界面。
你可以点击你想查询的有关机票的信息的按钮（舱位信息查询，客机信息查询，航线查询，客户类型信息查询）获得相关信息的表，根据表的内容，你可以在下面的下拉框中选择你要定的票信息，点确定后在下面会显示你的机票的相关内容，如果满意可以点击订票，把相关信息添加到机票数据库表中，如果不满意，可以点重置，所有信息清空，再重新选择。
4.退票功能。
用户可以根据用户信息表中的我的机票信息查询，找出机票号，在输入到机票号查询里，点击查询获得你的机票信息以及价格显示，点击退票则在数据库机票信息表中删除本条信息二、使用Rose绘制图分别有：用例图、类图、包图、顺序图、协作图、状态图、活动图、组件图、部署图情景：机票预订系统是某航空公司推出的一款网上选票系统。
使用UML对系统进行建模面向对象的软件工程，同传统的面向过程的软件工程相比，在需求的获取、系统分析、设计和实现方面都有着很大的区别。
UML是OOA和OOD的常用工具。
使用UML来构建软件的面向对象的软件工程的过程，就是一个对系统进行不断精化的建模的过程。
这些模型包括用例模型、分析模型、设计模型，然后，我们需要使用具体的计算机语言来建立系统的实现模型。
当然，在整个软件工程中，我们还需要建立系统的测试模型，以保证软件产品的质量。
使用面向对象的工具来构建系统，就应该使用面向对象的软件工程方法。
然我，我们经常会发现，在实际的开发过程中，很多开发人员虽然能够理解UML的所有图形，却仍然不能得心应手的使用UML来构建整个项目，其很大的原因，是仍然在使用原有的软件工程方法，而不清楚如何使用UML来建立系统的这些模型，不清楚分析和设计的区别，以及他们之间的转化。
应用软件系统，就其本质来说，是使用计算机对现实世界进行的数字化模拟。
应用软件的制造过程，按照UML的方法，就是建立这一些列模型的过程。
本文将就一个图书馆系统，说明如何使用UML来对系统进行这一系列的建模。
关于这个图书馆系统，基本的需求比较简单，就是允许学生可以在图书馆借阅和归还图书，另外，也可以通过网络或者图书馆的终端来查阅和预订书。
当然，图书馆管理员也可以对图书进行管理。
为了简化系统，我们没有把图书馆中的人员作细分。
之所以采用这个相对简单案例，是因为很多人都对图书馆系统有很强的感性认识，这样，读者不需要花很多的时间来理解系统包含的业务知识。
同时，也因为本文只是对使用UML 的过程做一个探讨，着眼于使用UML进行建模的过程，说明各个层次的模型之间的区别和联系，展示系统演进的过程，而不会深入UML的细节方面。
对于更加复杂的系统，其分析和设计的方法是相通的，可以举一反三。
用例模型——系统需求的获取用例模型定义系统做什么，是用来获取系统需求的有效手段。
用例模型由“角色”和“用例”组成。
UML各种图例——用例图、类图、状态图、包图、协作图、顺序图面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.∙决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.每个类图包括类，关联和多样性表示.方向性和角色是为了使图示得更清楚时可选的项目.包和对象图为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型. dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。
ＵＭＬ在ＡＴＭ自动取款机中的应用(一)Uml 基础知识Uml 概述UML （Unified Modeling Language)是软件界第一个统一的建模语言，该方法结合了Booch ， OMT ，和OOSE 方法的优点，统一了符号体系，并从其它的方法和工程实践中吸收了许多经过实际检验的概念和技术.它是一种标准的表示,已成为国际软件界广泛承认的标准。
是一种基于面向对象的可视化的通用（General ）建模语言。
为不同领域的用户提供了统一的交流标准 — UML 图。
UML 应用领域很广泛,可用于软件开发建模的各个阶段，商业建模（Business Modeling ）, 也可用于其它类型的系统。
UML 是一种定义良好,易于表达，功能强大且普遍实用的建模语言，不是一种方法，它独立于过程。
利用它建模时，可遵循任何类型的建模过程。
建模过程：UML 的主要构成向对象分析与设计的一种UML 是一种标准化的图形建模语言,它是面向对象分析与设计的一种标准表示.由：● 视图（views ）, ● 图(Diagrams ）,● 模型元素（Model elements ） ● 通用机制（general mechanism ）等几个部分构成。
视图(views）一个系统应从不同的角度进行描述，从一个角度观察到的系统称为一个视图（view）。
视图由多个图（Diagrams）构成，它不是一个图表(Graph）,而是在某一个抽象层上，对系统的抽象表示。
如果要为系统建立一个完整的模型图，需定义一定数量的视图,每个视图表示系统的一个特殊的方面。
另外，视图还把建模语言和系统开发时选择的方法或过程连接起来。
图(Diagrams）UML语言定义了五种类型9种不同的图，把它们有机结合起来就可以描述系统的所有视图。
用例图(Use case diagram）从用户角度描述系统功能，并指出各功能的操作者。
静态图（Static diagram)，表示系统的静态结构.包括类图、对象图、包图。
UML中各种图的画法(全)UML中各种图的画法(全)一、UML中基本的图范畴：在 UML 2 中有二种基本的图范畴：结构图和行为图。
每个 UML 图都属于这二个图范畴。
结构图的目的是显示建模系统的静态结构。
它们包括类，组件和（或）对象图。
另一方面，行为图显示系统中的对象的动态行为，包括如对象的方法，协作和活动之类的内容。
行为图的实例是活动图，用例图和序列图。
二、UML中的类图：1.类图的表示：类的 UML 表示是一个长方形，垂直地分为三个区，如图 1 所示。
顶部区域显示类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。
描述：顶部区域显示类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。
·类名：如果是抽象类，则采用斜体·类属性列表：name : attribute type 如 flightNumber : Integer，这是最常见的表达形式n ame : attribute type = default value 如balance : Dollars = 0，这是带有默认值的表达形式·类方法列表：name(parameter list) : type of value returned注意：在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。
然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。
2.继承的表示：为了在一个类图上建模继承，从子类（要继承行为的类）拉出一条闭合的，单键头（或三角形）的实线指向超类。
