用UML建立表示数据的类模型
- 格式:doc
- 大小:52.50 KB
- 文档页数:3
浅谈UML中常用的几种图1 UML简介2 UML常见图分类3 用况图(用例)4 类图简单类图使用举例5 其他辅助用图●时序图(顺序图)●协作图(Collaboration Diagram/communication Diagram)/通信图●状态图●活动图(Activity Diagram)6 组件图(ComponentDiagram)、配置图(Deployment Diagram)1 UML简介统一建模语言(Unified Modeling Language,UML)又称标准建模语言,是始于1997年的一个OMG标准,它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持,包括由需求分析到规格,到构造和配置。
‘UML感兴趣的可以阅读UML 1规范,包含了UML 的所有知识内容。
注:OMG, Object Management Group 对象管理组织2 UML常见图分类UML从考虑系统的不同角度出发,定义了用况图、类图、对象图、包图、状态图、活动图、序列图、通信图、构件图、部署图等10种图。
分类:面向对象动态建模,用于建立行为的实体间行为交互的四种图:状态图(Stage Diagram),序列图(Sequence Diagram),协作图(Communication Diagram),活动图(Activity Diagram) 。
“序列图”与“协作图”表述的是相似的消息,“活动图”是“状态图”的一种。
•静态结构图Static Structure Diagram•类图Class Diagram•对象图Object Diagram•用况图Use Case Diagram•交互图Interaction Diagram•顺序图Sequence Diagram•协作图Collaboration Diagram•状态图State chart Diagrams•活动图Activity Diagrams•实现图Implementation Diagrams•构件图Component Diagram•部署图Deployment Diagram3 用况图(用例)用例图,展现了一组用例、参与者(actor)以及它们之间的关系。
某大学教务管理系统UML模型随着高校校园网的建设和Internet技术的引进,基于校园网和Internet的应用系统的开发正在蓬勃发展。
教务管理师高校教学管理的一向重要工作,现代化的高校教务管理需要现代化的信息管理系统支持。
新世纪背景下,高校教育体制进行了大规模的改革,招生人数逐年增加,教学计划不断更新。
在高校日常管理中,教务管理无疑是核心工作,重中之重。
其管理模式的科学化与规化,管理手段的信息化与自动化对于学校的总体发展产生深远的影响,由于管理容过多,繁琐,处理的过程也非常复杂,并且随着学校人员的增加,教务管理系统的信息量大幅上升,因此往往很难及时准确地掌握教务信息的运作状态这使得高校教务管理的工作量大幅度增加,另外,随着教育改革的不断深化,教学管理模式也在发生变化,例如实施学分制、学生自主选课等。
这一切都有赖于计算机网络技术和数据库技术的支持,在这样的形势下建立和完善一个集成化的教务管理系统势在必行。
目前,国高校都开发了自己基于校园网的教务管理系统。
由于其教务管理模式不尽相同,不同学校的实际教务管理情况各有自己的特点,因而各高校需要针对自己的教务管理模式和特点建立自己的教务管理系统。
本设计是基于某高校的教务管理模式开发的基于校园网的教务管理系统。
这样一个系统不仅可以降低工作量、提高办公效率,而且使分散的教务信息得到集中处理,对减轻教务工作负担、提高教务管理水平、实现教务管理的现代化具有重要意义。
1.建立系统用例模型1.1确定系统模型的参与者仔细分析教务管理系统问题描述。
在UML中,角色代表位于系统之外和系统进行交互的一类对象,本系统中创建主要的角色有以下三类:(1)教务员:教务员在教学管理系统中对全体学生进行用户登录、学籍管理、选课管理、教学管理和成绩管理,并且对教师进行登录管理、教学管理和成绩管理。
教务处工作人员处理日常的系统维护,例如维护和及时更新学生,教师信息以及安排选课等。
(2)教师:教师根据教务系统的选课安排进行教学,将学生的考试成绩录入此系统。
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.标准文档UML类的符号是一个被划分成三块的方框:类名,属性,和操作.抽象类的名字,像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association-表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中,关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图,可以把类组合成包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.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。
目录1.类图和对象图的概念2.类图的组成3.使用Rose创建类图4.对象图5.使用Rose创建类图案例分析类图和对象图详解对于类图和对象图来说我们需要了解的是类图和对象图的概念,类图的组成,使用Rose创建类图和对象图。
当然最重要的是如何使用Rose创建类图案例分析。
具体的创建通过选课管理系统的简单用例说明创建类图和对象图的方法和具体的过程。
下面是我对类图和对象图学习过程的一个整理,一些资料是直接拿过来直接用的。
希望能对你的学习有一点点的帮助吧。
类图和对象图的概念1. 类的含义类图(Class diagram)显示了系统的静态结构,而系统的静态结构构成了系统的概念基础。
类图,就是用于对系统中的各种概念进行建模,并描绘出它们之间关系的图。
在大多数的 UML 模型中,我们可以将这些概念的类型概括为以下四种,分别是:(1) 类(2) 接口(3) 数据类型(4) 构件在类图中,具体来讲它一共包含了以下几种模型元素,分别是:类、接口、依赖关系、泛化关系、关联关系以及实现关系。
类图可以创建约束、注释和包等。
2. 对象图的含义对象图中包含对象(Object)和链(Link)。
其中对象是类的特定实例,链是类之间关系的实例,表示对象之间的特定关系。
3. 类图在项目开发中的作用类图的作用是对系统的静态视图进行建模。
当对系统的静态视图进行建模时,通常是以以下三种方式来使用类图。
(1)为系统的词汇建模。
(2)模型化简单的协作。
(3)模型化逻辑数据库模式。
在设计数据库时,通常将数据库模式看作为数据库概念设计的蓝图,在很多领域中,都需要在关系数据库或面向数据库中存储永久信息。
系统分析者可以使用类图来对这些数据库进行模式建模。
4. 对象图在项目开发中的作用对象图作为系统在某一时刻的快照,是类图中的各个类在某一个时间点上的实例及其关系的静态写照,可以通过以下几个方面来说明它的作用:(1)说明复杂的数据结构。
对于复杂的数据结构,有时候很难对其进行抽象成类表达之间的交互关系。
UML中数据流图,⽤例图,类图,对象图,⾓⾊图,活动图,序列图详细讲述保存供参考这个⽂章,是我在急需的情况下在园⼦⾥搜索到的,原创作者是:DO-websoftware,为了⾃⼰看⽅便,所以复制到我的空间,希望原创者不要介意哦~~~~很详细的介绍,对我的帮助很⼤,谢谢哦。
类图,对象图,⾓⾊图:⼀、UML中基本的图范畴:在 UML 2 中有⼆种基本的图范畴:结构图和⾏为图。
每个 UML 图都属于这⼆个图范畴。
结构图的⽬的是显⽰建模系统的静态结构。
它们包括类,组件和(或)对象图。
另⼀⽅⾯,⾏为图显⽰系统中的对象的动态⾏为,包括如对象的⽅法,协作和活动之类的内容。
⾏为图的实例是活动图,⽤例图和序列图。
⼆、UML中的类图:1.类图的表⽰:类的 UML 表⽰是⼀个长⽅形,垂直地分为三个区,如图 1 所⽰。
顶部区域显⽰类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
在⼀个类图上画⼀个类元素时,你必须要有顶端的区域,下⾯的⼆个区域是可选择的(当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时,下⾯的两个区域是不必要的)。
描述:顶部区域显⽰类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
当在⼀个类图上画⼀个类元素时,你必须要有顶端的区域,下⾯的⼆个区域是可选择的(当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时,下⾯的两个区域是不必要的)。
·类名:如果是抽象类,则采⽤斜体·类属性列表:name : attribute type 如 flightNumber : Integer,这是最常见的表达形式name : attribute type = default value 如 balance : Dollars = 0,这是带有默认值的表达形式·类⽅法列表:name(parameter list) : type of value returned注意:在业务类图中,属性类型通常与单位相符,这对于图的可能读者是有意义的(例如,分钟,美元,等等)。
UML建模—EA创建Class(类图)1.新建类图2.添加类或接⼝在类图可以捕获系统-类-和模型组件的逻辑结构。
它是⼀个静态模型,描述存在什么,有哪些属性和⾏为,⽽不管如何去做。
说明关系之间的类和接⼝; 泛化、聚合和关联是在分别反映继承、组成或使⽤和连接。
3.⼯具栏从⼯具箱中的类页⾯选择类图元素和连接器。
(1)Package:包包是⼀个命名空间,也是⼀个元素。
可以包含在其它命名空间中。
包可以拥有其他包或与其他包合并,它的元素可以导⼊包命名空间中。
除了要在项⽬浏览器中使⽤包来组织您的项⽬的内容外,您还可以拖动包到图中图 (⼤多数图类型、标准和扩展)以描述结构或关系,包括包的导⼊或合并。
(2)Interface: 接⼝接⼝是实施者需要满⾜的⾏为规范(或合同)。
通过实现接⼝,类可以保证提供所需的⾏为,系统可以相同的⽅式处理⾮相关元素;也就是说,您通过共同的接⼝,使⽤复合结构图中的接⼝。
接⼝是绘制⽅式类似于类,指定操作,如下所⽰。
它们可以还可以被画成⼀个圆圈,但没有显式的操作。
右击该元素并选择使⽤圆表⽰法上下⽂菜单选项样式,可以在两者之间进⾏切换。
实现以⽆⽬标箭头的实线绘制画成⼀个圆的接⼝连接器。
接⼝不能实例化(即,不能从接⼝创建对象)。
您必须创建该类实现接⼝规范,并在类中定义每个接⼝操作。
然后,您可以实例化类。
(3)Class: 类类是对象类型的表现形式。
反映出这类对象在系统内的的结构和⾏为。
它是⼀个模板,⽤它可以创建实际运⾏的实例,虽然类可以定义控制其⾃⼰的执⾏,或者定义为模板或参数类,必须由任何绑定类定义指定参数。
类可以有属性(数据)和⽅法 (操作或⾏为)。
类可以从⽗类别继承特征和委托其他类的⾏为。
类模型通常描述系统的逻辑结构,⽽是构成组件的构造块。
类的顶部,如下所⽰,显⽰与类关联的属性(或数据元素)。
这些包含对象在运⾏时的状态。
如果该信息保存到数据存储区,并可以重新加载,它被称为持久的。
下半部分包含类的操作(或在运⾏时的⽅法)。
昆明理工大学信息工程与自动化学院学生实验报告
(2010—2011学年第 2 学期)
课程名称:面向对象分析与设计开课实验室:计算中心208 2011年6月6日
一、实验内容和目的
用UML建立表示数据的类模型
二、实验原理及基本技术路线图(方框原理图)
在软将工程实践中经常遇到通过分析表得到数据模型的工作,目的是通过一组数据实例的分析,找到内在的关系,进而得到数据模型。
在面向对象技术中,数据模型也是由对象构成的,这些对象的抽象是实体类,实体类的关系有继承、关联、聚合等,通过对下图数据的分析,可以得到反映这些对象关系的类图。
三、所用仪器、材料(设备名称、型号、规格等)
windows xp PowerDesigner 15.1
四、实验内容:
建立代表数据模型的类图;类的属性、类之间的关系需要讨论对应的数据对象依据。
五、实验方法、步骤、实验过程原始记录
1.分析表中的数据:
2.数据的类模型:
六.实验结论
通过本次试验了解了数据(data)是描述事物的符号记录。
模型(Model)是现实世界的抽象。
数据模型(Data Model)是数据特征的抽象,数据模型按不同的应用层次分成三种类型:分别是概念数据模型、逻辑数据模型、物理数据模型。
1、概念数据模型(Conceptual Data Model):简称概念模型,是面向数据库用户的实现世界的模型,主要用来描述世界的概念化结构,它使数据库的设计人员在设计的初始阶段,摆脱计算机系统及DBMS的具体技术问题,集中精力分析数据以及数据之间的联系等,与具体的数据管理系统(Database Management System,简称DBMS)无关。
概念数据模型必须换成逻辑数据模型,才能在DBMS中实现。
2、逻辑数据模型(Logical Data Model):简称数据模型,这是用户从数据库所看到的模型,是具体的DBMS所支持的数据模型,如网状数据模型(Network Data Model)、层次数据模型(Hierarchical Data Model)等等。
此模型既要面向用户,又要面向系统,主要用于数据库管理系统(DBMS)的实现。
3、物理数据模型(Physical Data Model):简称物理模型,是面向计算机物理表示的模型,描述了数据在储存介质上的组织结构,它不但与具体的DBMS有关,而且还与操作系统和硬件有关。
每一种逻辑数据模型在实现时都有起对应的物理数据模型。
DBMS为了保证其独立性与可移植性,大部分物理数据模型的实现工作又系统自动完成,而设计者只设计索引、聚集等特殊结构。