Myeclipse中把java代码导成UML类图1、右键点击项目名称，选择New-------àUML2 Model
2、给类图命名
3、导成类图
1）如果要把整个项目导成类图，则把整个项目拖到类图中
2）如果要把单个类导成类图，则把单个java类拖到类图中
4、右键点击类图，选择Export All Diagrms
5、点击Browse选择导成的类图的路径，选择导出的图片的格式，点击finish,生成图片。
必须把非java的比如xml之类的排除出去，否则插件会报错弹出。
Generate class diagrams from entity relationship diagrams Written Date : October 30, 2009 Visual Paradigm for UML (VP-UML) supports generating class diagrams from ER diagrams (entity relationship diagram). Entities and relationships are mapped with classes and associations accordingly. This tutorial teaches generating class diagrams from entity relationships diagrams and how to synchronize documentation between classes and entities. To generate class diagrams from entity relationship diagrams: 1.We first create Entity Model in Model Explorer. Right click on the Model Explorer and select Model > New Model. Create entity model in Model Explorer 2.Enter the name as Entity Model. Input "Entity Model" in model specification dialog box
UML软件建模教程课后习题 习题 1 一、简答题 1. 简述模型的作用。 答：现实系统的复杂性和内隐性，使得人们难于直接认识和把握，为了使得人们能够直观和明了地认识和把握现实系统，就需要借助于模型。 2. 软件模型有什么特征？ 答：建模对象特殊，复杂性，多样性 3. 软件建模技术有哪些因素？ 答：软件建模方法，软件建模过程，软件建模语言，软件建模工具 4. 软件模型包括哪些方面的内容？ 答：从模型所反映的侧面看：功能模型，非功能模型，数据模型，对象模型，过程模型，状态模型，交互模型，架构模型，界面模型等；从软件开发工作看：业务模型，需求模型，分析模型，设计模型，测试模型等。 5. 软件建模工具应该具有哪些基本功能？ 答：软件模型的生成和编辑，软件模型的质量保障，软件模型管理等 二、填空题 1、模型是对现实的（抽象）和模拟，是对现实系统（本质）特征的一种抽象、简化和直观的描述。
2、模型具有（反映性）、直观性、（简化性）和抽象性等特征。 3、从抽象程度，可以把模型分为（概念模型）、逻辑模型和（物理模型）三种类型。 4、较之于其他模型，软件模型具有（建模对象特殊）、复杂性和（多样性）等特征。 5、软件模型是软件开发人员交流的（媒介），是软件升级和维护的（依据）。 6、软件建模技术的要素包括软件建模方法、（软件建模过程）、软件建模语言和（软件建模工具）。 7、从开发阶段看，软件建模有业务模型、（需求模型）、分析模型、（设计模型）和测试模型。 8、软件语言有软件需求定义语言、（软件设计语言）、软件建模语言、（软件结构描述语言）、软件程序设计语言等。 9、根据软件建模工具的独立性，把软件建模工具分为（独立软件）建模工具和（插件式软件）建模工具。 10、OMG在（ 1997 ）年把UML作为软件建模的标准，UML2.0版本是（ 200 5 ）年颁布的。 三、选择题 1、对软件模型而言，下面说法错误的是（ D ）。 A.是人员交流的媒介 B.是软件的中间形态 C.是软件升级和维护的依据 D.是软件的标准文档
UML类图关系大全(ROSE画图) 1、关联 双向关联： C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。 在GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。 使用ROSE 生成的代码是这样的： class C1 ...{ public: C2* theC2; }; class C2 ...{ public: C1* theC1; };
双向关联在代码的表现为双方都拥有对方的一个指针，当然也可以是引用或者是值。 单向关联: C3->C4：表示相识关系，指C3知道C4，C3可以调用C4的公共属性和方法。没有生命期的依赖。一般是表示为一种引用。 生成代码如下： class C3 ...{ public: C4* theC4; }; class C4 ...{ }; 单向关联的代码就表现为C3有C4的指针，而C4对C3一无所知。
自身关联（反身关联）： 自己引用自己，带着一个自己的引用。 代码如下： class C14 ...{ public: C14* theC14; }; 就是在自己的内部有着一个自身的引用。 2、聚合/组合 当类之间有整体-部分关系的时候，我们就可以使用组合或者聚合。 聚合：表示C9聚合C10，但是C10可以离开C9而独立存在（独立存在的意思是在某个应用的问题域中这个类的存在有意义。这句话怎么解，请看下面组合里的解释）。
UML用例图 用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块。展示了一个外部用户能够观察到的系统功能模型图。 用例图中涉及的关系： 1》泛化(Inheritance) 就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。 2》包含(Include) 包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。 3》扩展(Extend) 扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
1 一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。在 UML 2 中，一个接口被认为是类建模元素的特殊化。因此，接口就象类那样绘制，但是长方形的顶部区域也有文本“interface”。 2》UML 支持的可见性类型的标志 3》多重值和它们的表示 4》类图之间的关系有：泛化（继承），依赖，关联，聚合/组合。 1.聚合/组合
聚合是一种特别类型的关联，用于描述“总体到局部”的关系。在基本的聚合关系中，部分类的生命周期独立于整体类的生命周期。 举例来说，我们可以想象，车是一个整体实体，而车轮轮胎是整辆车的一部分。轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。在这个实例中，Wheel类实例清楚地独立地Car类实例而存在。然而，有些情况下，部分类的生命周期并不独立于整体类的生命周期 -- 这称为合成聚合。举例来说，考虑公司与部门的关系。公司和部门都建模成类，在公司存在之前，部门不能存在。这里Department类的实例依赖于pany类的实例而存在。 ·基本聚合（聚合） 有聚合关系的关联指出，某个类是另外某个类的一部分。在一个聚合关系中，子类实例可以比父类存在更长的时间。为了表现一个聚合关系，你画一条从父类到部分类的实线，并在父类的关联末端画一个未填充棱形。 图中清楚的表明了类Car对象包含了另一类Wheel的4个实例，这两者在概念上是密不可分的，其中的一个类是另一个类的构成成分。菱形表示“包含”，箭头表示被包含的对象，数字4表示包含的数目。 ·组合聚合（组合） 组合聚合关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期。 注意:组合关系如聚合关系一样绘制，不过这次菱形是被填充的。 2.依赖 依赖可以说是要完成C5里的所有功能，一定要有C6的方法协助才行 3.关联 可以分为单向关联，双向关联 双向关联： C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。 单向关联：
UML类图与关系数据库之间的映射策略 摘要：UML是目前面向对象程序设计中的一种标准的建模技术。在关系数据库系统的设计过程中，我们可先利用UML建立商业模型，然后将其映射成表。本文主要讨论如何将UML 类图中的类映射成表的策略。 关键词：UML 类表关系建模映射 一．概论 在关系数据库设计中，用来创建数据库逻辑模型的标准方法是使用实体关系模型（ER 模型）。ER模型的中心思想是：可以仅通过实体和它们之间的关系合理地体现一个组织的数据模型。但这样做似乎对描述一个组织的信息过于简单化，并且词汇量也远远不足。所以，迫切需要使用更加灵活、健壮的模型来代替ER模型。 标准建模语言UML是由世界著名的面向对象技术专家发起的，在综合了著名的Booch 方法、OMT方法和OOSE方法的基础上而形成的一种建模技术，它通过用例图、类图、交互图、活动图等模型来描述复杂系统的全貌及其相关部件之间的联系。UML可以完成ER 模型的所有建模工作，而且可以描述ER模型所不能表示的关系。 在UML中，类图主要用于描述系统中各种类及其对象之间的静态结构。在关系数据库领域中，类与表相对应。本文主要讨论将UML类图中的类及其对象映射成关系型数据库中的表的策略。 二．UML类图中的类映射成表的策略 UML中的类图主要由类及其关系组成，而类之间的关系又可以细分为： （1）泛化：在UML类图中，如果子类型的接口包括超类型的接口中的每个元素。则超类与子类之间构成泛化关系。泛化通常可以用继承或授权的方式实现。 （2）关联：在UML类图中，关联表示类的实例之间存在的某种关系。它通常可以有1对1、1对多和多对多等情形。 （3）聚集：在UML类图中，聚集描述了部分与整体之间的关系。 （4）组成：在UML类图中，组成由聚集演变而成，它表示一个部分对象仅属于一个整体，并且部分对象通常与整体对象共存亡。 下面结合例子，分别讨论在将类映射成表的过程中这些关系的实现技术。 假设，有一个电脑公司专门从事软件开发，其项目主要由项目开发部门承担，它们之间构成多对多的关联（即一个项目可由多个部门承担，而一个部门又可以承担多个项目的开发工作）；项目开发部门由经理及一般职员组成，项目开发部门和组成人员之间构成聚集关系，而人（抽象类）又可以进一步和一般职员及经理两个子类之间构成继承关系；每个项目具有一定的属性，它们之间构成组成关系。 综上所述，其主要关系的UML类图如图1所示。
分析了UML的几个重要图看看是否可以？ 第2章用例图 1．一台自动售货机能提供6种不同的饮料，售货机上有6个不同的按钮，分别对应这6种不同的饮料，顾客通过这些按钮选择不同的饮料。售货机有一个硬币槽和找零槽，分别用来收钱和找钱。现在为这个系统设计一个用例图？ 顾客 2．现有一个产品销售系统，其总体需求如下： 系统允许管理员生成存货清单报告。 管理员可以更新存货清单。 销售员记录正常的销售情况。 交易可以使用信用卡或支标，系统需要对其进行验证。 每次交易后都需要更新存货清单。 分析其总体需求，并绘制出其用例图？ 3．绘制用例图，为如下的每个事件显示酒店管理系统中的用例，并描述各用例的基本操作流程。 客人预订房间。 客人登记。 客人的承担服务费用。 生成最终账单 客人结账 客人支付账单
第3章类图、对象图和包图 1．创建一个类图。下面给出创建类图所需的信息。 ●学生（student）可以是在校生（undergraduate）或者毕业生（graduate）。 ●在校生可以是助教（tutor）。 ●一名助教指导一名学生。 ●教师和教授属于不同级别的教员。 ●一名教师助理可以协助一名教师和一名教授，一名教师只能有一名教师助理，一名 教授可以有5名教师助理。 ●教师助理是毕业生。 创建类图的步骤如下： （1）将学生可以是在校生或者毕业生建模为3个类：Student、UnderGraduate和Graduate，其中，后两个类是Student类的子类。 （2）为“在校生可以是助教的一种”建立模型，即建立UnderGraduate类的另一个超类Tutor。 （3）通过创建从Tutor到Student的关联（名为tutors），建立一名助教指导一名学生的模型。 （4）将“教师和教授属于不同级别的教员”建模为3个类：Instructor、Teacher和Professor，其中，后两个类是Instructor类的子类。 （5）建立“一名教师助理可以协助一名教师和一名教授，一名教师只能有一名教师助理，一名教授可以有5名教师助理”的模型。创建TeacherAssistant类，并使其与Teacher 类和Professor类都建立关联。 （6）将TeacherAssistant类建模为Graduate类的派生类。
父用例通常是抽象的。
1 一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。在 UML 2 中，一个接口被认为是类建模元素的特殊化。因此，接口就象类那样绘制，但是长方形的顶部区域也有文本“interface”。 2》UML 支持的可见性类型的标志 3》多重值和它们的表示
4》类图之间的关系有：泛化（继承），依赖，关联，聚合/组合。 1.聚合/组合 聚合是一种特别类型的关联，用于描述“总体到局部”的关系。在基本的聚合关系中，部分类的生命周期独立于整体类的生命周期。 举例来说，我们可以想象，车是一个整体实体，而车轮轮胎是整辆车的一部分。轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。在这个实例中，Wheel类实例清楚地独立地Car类实例而存在。然而，有些情况下，部分类的生命周期并不独立于整体类的生命周期-- 这称为合成聚合。举例来说，考虑公司与部门的关系。公司和部门都建模成类，在公司存在之前，部门不能存在。这里Department类的实例依赖于Company类的实例而存在。 ·基本聚合（聚合） 有聚合关系的关联指出，某个类是另外某个类的一部分。在一个聚合关系中，子类实例可以比父类存在更长的时间。为了表现一个聚合关系，你画一条从父类到部分类的实线，并在父类的关联末端画一个未填充棱形。 图中清楚的表明了类Car对象包含了另一类Wheel的4个实例，这两者在概念上是密不可分的，其中的一个类是另一个类的构成成分。菱形表示“包含”，箭头表示被包含的对象，数字4表示包含的数目。 ·组合聚合（组合） 组合聚合关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期。 注意:组合关系如聚合关系一样绘制，不过这次菱形是被填充的。 2.依赖 依赖可以说是要完成C5里的所有功能，一定要有C6的方法协助才行 3.关联 可以分为单向关联，双向关联
UML类图关系（泛化、继承、实现、依赖、关联、聚合、组合） 继承、实现、依赖、关联、聚合、组合的联系与区别 分别介绍这几种关系： 继承 指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java 中此类关系通过关键字extends明确标识，在设计时一般没有争议性； 实现 指的是一个class类实现interface接口（可以是多个）的功能；实现是类与接口之间最常见的关系；在Java中此类关系通过关键字implements明确标识，在设计时一般没有争议性； 依赖 可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method
方法中使用； 关联 他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B 以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量； 聚合 聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与CPU、公司与员工的关系等；表现在代码层面，和关联关系是一致的，只能从语义级别来区分； 组合 组合也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束；比如你和你的大脑；表现在代码层面，和关联
第4章类图实战 4.1从分析到设计 首先，我们先来简单归纳一下在分析阶段生成的文件，如下： 1. 类图。类图描述系统内部的静态结构，以领域概念为参考对象。如果应用BCE 模式的话，原先的类图会是实体类图，而在序列图生成后，会额外生成边界类图和控制类图。 2. 用例图。用例图描述系统的外部行为，也就是描述参与者如何与系统交互，以便获取服务的使用过程。 3. 序列图。序列图描述系统的内部行为，针对每一个用例，至少会有一张描述主要流程的序列图。在应用BCE 模式之后，序列图内部的一群对象，将由边界对象、控制对象和实体对象所组成。换言之，序列图的一群对象必须来自于类图，而对象之间的交互过程，则来自于用例描述。 分析阶段与设计阶段最大的差别在于，分析阶段所关注的重点在领域概念、业务流程等，并未考虑并涉及实际工作平台。所以，到了设计阶段，不再需要花费太多时间在业务概念上，取而代之的是，必须把精力放在实际工作平台上，承接分析阶段的类图、用例图、序列图再加上实际工作平台或者是开发人员的观点，生成可以交付给程序员的设计文件。因此，在本书的开发流程规划中，我们会让设计师直接承接分析师的生成文件，进行下述的加工： 1. 类图。分析师所生成的类图通常跟实际工作平台有些差别，所以设计师要补上一些实际工作平台的概念，让设计出来的类图可以真正交付给程序员实际工作。 2. 用例图。之前我们没有教给分析师用例之间的包含关系和扩展关系如何处理，只是让用例图保持单纯化，以便将焦点聚焦在业务流程上。此处，我们会教设计师如何加入开发人员的观点，使用包含关系和扩展关系，罗列出可以共享的部分，并且让用例图更为细致化。 3. 序列图。在分析阶段的序列图并没有太重视消息上的参数，在设计阶段，每张序列图都要拿出来再检查一次，加上所需要的参数。由于，有些分析师已经太久没摸过程序代码了，所以生成的序列图偏离实际工作情况太大，需要设计师来补上这一块，否则程序员是很难直接参考分析文件编写程序代码。 好了，接下来，我们要再来多谈一些类图中的元素，这些元素可能对分析师意义不大，但是对设计师而言，会是非常实用的概念。 4.2设计师必学元素 4.2.1依赖关系 之前，我们学到了类之间的关联或组合关系，它们都是一种需要长期保存在数据库中的静态关系。相较之下，“依赖关系（dependency relationship）”是一种暂时的、动态的关系，它不需要被长期保存，可以在使用的瞬间建立，如果不用了就回收。 因此，当两个对象之间可以互传消息时，意味着两个对象之间存在需要长期保管的静态关系，或者是暂时性的动态关系。例如，在图4-1 中，边界对象与实体对象之间可以通过动态的依赖关系交互，用完就丢，不需要将这个动态关系保存在数据库中。而房型和景观图片两者之间由于存在组合关系，所以它们可以通过静态关系交互。
软件工程的5个阶段：需求分析(Requirements Capture)，系统分析与设计(System Analysis and Design)，实现(Implement)，测试(Test)，维护(Maintenance)。 2.UML的定义包括UML语义和UML表示法两个部分。UML语义描述基于UML 的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致和通用的定义性说明。UML表示法，为开发者或开发工具使用图形工具和文本语法为系统建模提供了标准。 3.UML(Unified Modeling Language)由视图(View)，图(Diagram)，模型元素(Model Element)，通用机制(General Mechanism)等组成，还提供了扩展机制(Extension Mechanism)，使得UML语言能够适应一个特殊的方法或者扩充到一个组织或用户。 a)视图是表达系统的某一方面特征的UML建模元素的子集，由多个图构成，是在某一个抽象层上，对系统的抽象表示。 b)图是模型元素集的图形表示，通常由弧(关系)和顶点(其他模型元素)相互连接构成。 c)模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的基本概念。 d)通用机制用于表示其他信息，比如注释、模型元素的语义等。 4.UML用模型来描述系统的结构或静态特征，以及行为或动态特征，从不同的视角为系统架构建模，形成不同视角： a)用例视图(Use Case View)，强调从用户角度看到的或需要的系统功能，是被称为参与者的外部用户所能观察到的系统功能的模型图。 b)逻辑视图(Logical View)，展现系统的静态或结构组成及特征，也被称为结构模型视图(Structural Model View)或者静态视图(Static View)。 c)并发视图(Concurrent View)，体现了系统的动态或者行为特征，也称为行为模型视图(Behavioral Model View)或动态视图(Dynamic View)。 d)组件视图(Component View)，体现了系统实现的结构和行为特征，也称为实现模型视图(Implementation Model View)。 e)配置视图(Deployment View)，体现了系统实现环境的结构和行为特征，也被称为环境模型视图(Environment Model View)或者物理视图(Physical View)。 5.视图由图构成，UML提供了9种不同的图： a)用例图(Use Case Diagram)，描述系统功能；
一．UML简介 UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。 二．用例建模简介 用例建模是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。依我的理解用例建模可分为用例图和用例描述。用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成。 1．用例图 参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。 用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。 系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
UML基础与Rose建模实用教程课后习题及答案 第1章面向对象概述 1. 填空题 （1）软件对象可以这样定义：所谓软件对象，是一种将状态和行为有机结合起来形成的软件构造模型，它可以用来描述现实世界中的一个对象。 （2）类是具有相同属性和操作的一组对象的组合，即抽象模型中的“类”描述了一组相似对象的共同特征，为属于该类的全部对象提供了统一的抽象描述。 （3）面向对象程序的基本特征是抽象、封装、继承和多态。 2. 选择题 （1）可以认为对象是ABC。 （A）某种可被人感知的事物 （B）思维、感觉或动作所能作用的物质 （C）思维、感觉或动作所能作用的精神体 （D）不能被思维、感觉或动作作用的精神体 （2）类的定义要包含以下的要素ABD。 （A）类的属性（B）类所要执行的操作 （C）类的编号（D）属性的类型 （3）面向对象程序的基本特征不包括B。 （A）封装（B）多样性 （C）抽象（D）继承 （4）下列关于类与对象的关系的说法不正确的是A。 （A）有些对象是不能被抽象成类的 （B）类给出了属于该类的全部对象的抽象定义 （C）类是对象集合的再抽象 （D）类用来在内存中开辟一个数据区，并存储新对象的属性 3. 简答题 （1）什么是对象？试着列举三个现实中的例子。 对象是某种可被人感知的事物,也可是思维、感觉或动作所能作用的物质或精神体,例如桌子.椅子.汽车等。 （2）什么是抽象？ 抽象是对现实世界信息的简化。能够通过抽象将需要的事物进行简化、将事物特征进行概括、将抽象模型组织为层次结构、使软件重用得以保证。 （3）什么是封装？它有哪些好处？ 封装就是把对象的状态和行为绑在一起的机制，使对象形成一个独立的整体，并且尽可能地隐藏对象的内部细节。封装有两个含义；一是把对象的全部状态和行为结合在一起，形成一个不可分割的整体。对象的私有属性只能够由对象的行为来修改和读取。二是尽可能隐蔽对象的内部细节，与外界的联系只能够通过外部接口来实现。通过公共访问控制器来限制对象的私有属性，使用封装具有以下好处：避免对封装数据的未授权访问、帮助保护数据的完整性、当类的私有方法必须修改时，限制了在整个应用程序内的影响。 （4）什么是继承？它有哪些好处？ 继承是指特出类的对象拥有其一般类的属性和行为。继承意味着“自动地拥有”，即在特殊类中不必重新对已经在一般类中定义过的属性和行为进行定义，而是特殊类自动地、隐含地拥有其一般类的属性和行为。通过继承可使派生类能够比不使用继承直接进行描述的类更加简洁、能够重用和扩展现有类库资源、使软件易于维护和修改。 （5）面向对象分析的过程有哪些？ 面向对象的分析的过程包括：获取需求内容陈述、建立系统的对象模型结构、建立对象的动态
UML实践----用例图、顺序图、状态图、类图、包图、协作图 2009-01-20 作者：Randy Miller 来源：网络 面向对象的问题的处理的关键是建模问题。建模可以把在复杂世界的许多重要的细节给抽象出。许多建模工具封装了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是指当某个人与系统进行互动时发生的情况。下面是一个医院门诊部的情节。 “一个病人打电话给门诊部预约一年一次的身体检查。接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录。”
UML从需求到实现（三）----类图 作者: 李守宏发布时间: 2011-04-02 09:51 按照UML中图的出现顺序.当做完包图以后.我们下一步要做的当然是类图,类图也是UML中的三大核心图之一. 看到很多文章在描述类图的时候.总是大部分在叙述类之间的关系:关联,依赖,继承,组合,聚合呀这些.很少有人说明类是怎么来的.没有了类,你拿什么来画类图.那些关系其实没有多大意义.就像是象棋的马走日,象飞 天一样.只是一个规定.你知道了这些就是一个象棋高手吗? 类图是UML中的一种静态图.他是体现面向对象编程的基础.类图就像是软件设计的细胞.是基本元素.没有了类图.也就没有了接下来的设计.但是类不可能是凭空产生的.类是我们凭借自己的经验和智慧去抽象,提取出来的. 所以说,对于一个良好的系统.如何去提取出类来.才是最关键的.下面我介绍一下面向对象开发过程中.利用三层架构的方式.分析典型MIS系统的类图从提出类.到类图的生成的过程. 一:根据用例确定数据库,确定表,创建实体类 第一个也是最关键的一个.我们要做的第一步就是要根据用户对数据的要求,去确定数据库中的表.去设计数据库(如何去设计数据库中的表,这里不在叙述). 因为我们在信息管理系统中.所有的操作可以说都是对数据的操作.你首先要确定的是数据.确定了数据,你才知道怎么操作(这个仅仅是我的个人体会).就像是你要谈恋爱.你首先要确定你要追求的目标.才能制定追
求的方法.如果你连个目标也没有.整天和别人说你要谈恋爱.别人会怎么想你? 然后根据设计好的数据库,一一对应的方式设计成实体类.实体类可以说就是数据库的映射.把数据库的每一个表影射成一个类,每一个字段设计成一个属性.这样保证你的操作是面向对象的.对于一条记录,你可以整体去操作它.如下图: PS:这里我要补充一点.很多人不理解实体类是干什么的.不知道该把它放在三层架构的那一层.其实实体类不属于三层的任何一层.其实它就是一个自定义的变量.你这么理解他就行了. 就像是你的string,int型变量一样.你用它来存放数据就对了.不同地方就是它可以放多个不同类型的变量而已.
ER 图、对象联系图和类图的特征与比较 第一部分：简述 ER 图，对象联系图和类图的基本概念和特点 ER 图： ER 图是用来表示实体联系模型( Entity Relationship Model )的方式，这个模型可以直 接从现实世界中抽象出实体类型和实体间的联系。举个例子来说。 ER 图的约定表示方法。 矩形框，表示实体类型(即考虑问题的对象) 菱形框，表示联系类型(即实体间的联系) 椭圆形框，表示实体类型和联系类型的属性(对于键的属性，在属性下面划一 条横线) 直线，联系类型与其涉及的实体类型之间用直线相连，用来表示他们之间的联 系，在直线 端部标注联系的种类(1:1,1:N,M:N ) 再通过一个例子来说明用 ER 图表示现实世界的特点： 1)考虑零件和工程的关系，零件可以服务于不同的工程，一个工程也需要各种不 同的零 件，因此，建模的时候零件和工程是一个多对多的联系。 a) b) c) d) J#、项目名称JNAME 、项目开工日期 DATE ；而part 的属性有零件号 P#、 零件名PNAME 、零件颜色 COLOR 以及零件重量 WEIGHT 。联系类型 从上面的可以看出，ER 图作为对现实世界的抽象，可以很方便的表示出现实 中实体以及实体间的联系， 不同形状的框代表不同的概念， 让读者一目了然哪些是 实体，哪些是联系，哪些是属性。实体间的数量对应关系也通过连线两端的数字记 号体现出来了。可以说， ER 图是一种简洁的模拟现实世界的符号方法。 对象联系图： 使用类型构造图的思想， 可以把ER 图扩充成为对象联系图。 对象联系图可以完整地揭 示数据间的联系。 对象联系图有一下几个基本成分： F 面对上述例子做一个说明，同时给出 (1) (2) (3) (4) 首先确定实体类型，这个例子 中， 再确定联系类型，正如前面所述， 把实体类型和联系类型组合成 确定实体类型和联系类型的 实体只有两个，就是工程和零件 工程和零件的关系是 M:N 的关系 ER 图(见图1) 在这个例子中，Project 的属性有项目号
UML类图关系汇总 关系 后面的例子将针对某个具体目的来独立地展示各种关系。虽然语法无误，但这些例子可进一步精炼，在它们的有效范围内包括更多的语义。 依赖（Dependency）（内部类） 实体之间一个“使用”关系暗示一个实体的规范发生变化后，可能影响依赖于它的其他实例（图D）。更具体地说，它可转换为对不在实例作用域内的一个类或对象的任何类型的引用。其中包括一个局部变量，对通过方法调用而获得的一个对象的引用（如下例所示），或者对一个类的静态方法的引用（同时不存在那个类的一个实例）。也可利用“依赖”来表示包和包之间的关系。由于包中含有类，所以你可根据那些包中的各个类之间的关系，表示出包和包的关系。 图D 关联（Association） 实体之间的一个结构化关系表明对象是相互连接的。箭头是可选的，它用于指定导航能力。如果没有箭头，暗示是一种双向的导航能力。在Java中，关联（图E）转换为一个实例作用域的变量，就像图E的“Java”区域所展示的代码那样。可为一个关联附加其他修饰符。多重性（Multiplicity）修饰符暗示着实例之间的关系。在示范代码中，Employee可以有0个或更多的TimeCard对象。但是，每个TimeCard只从属于单独一个Employee。 图E
聚合（Aggregation） 聚合（图F）是关联的一种形式，代表两个类之间的整体/局部关系。聚合暗示着整体在概念上处于比局部更高的一个级别，而关联暗示两个类在概念上位于相同的级别。聚合也转换成Java中的一个实例作用域变量。 关联和聚合的区别纯粹是概念上的，而且严格反映在语义上。聚合还暗示着实例图中不存在回路。换言之，只能是一种单向关系。 图F 合成（Composition） 合成（图G）是聚合的一种特殊形式，暗示“局部”在“整体”内部的生存期职责。合成也是非共享的。所以，虽然局部不一定要随整体的销毁而被销毁，但整体要么负责保持局部的存活状态，要么负责将其销毁。局部不可与其他整体共享。但是，整体可将所有权转交给另一个对象，后者随即将承担生存期职责。 Employee和TimeCard的关系或许更适合表示成“合成”，而不是表示成“关联”。 图G
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）
UML中的用例(Use Case)概念分析及实例 文/登峰 2005-02-25 在UML中use case似乎最簡單的，用例建模的最主要功能就是用来表达系统的功能性需求或行为，依我的理解用例建模可分为用例图和用例描述。用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成，以及由箭头所组成的各种关系，包括泛化，包含，扩展等。本文准备向大家介绍以下内容,所有图示均用PowerDesigner所画. ◆用况 ◆参与者 ◆泛化 ◆<
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。 ３．泛化 泛化和类中的泛化概念是一样的，子用况继承父用况的行为和含义，还可以增加或覆盖父用况的行为;子用况可以出现在任何父用况出现的位置（父和子均有具体的实例）。下面给出两种图示来说明泛化的概念和含义 图２含义继承图３行为继承 ４．<
UML 用例图：准则 在 Visual Studio 旗舰版中，可以绘制“用例图”来概括使用您的应用程序或系统的用户以及该应用程序或系统的用途。若要创建 UML 用例图，请在“体系结构”菜单上，单击“新建关系图”。 用例图有助于讨论和传达以下内容： 您的系统或应用程序与人、组织或外部系统进行交互的几种方案。 它帮助参与者实现的目标。 系统的范围。 用例图不显示用例的详细信息：它只概括用例、参与者和系统之间的某些关系。特别是，用例图不显示每个用例为实现目标所执行步骤的顺序。可以在其他关系图和文档中描述这些详细信息，这些关系图和文档可与各用例相链接。有关更多信息，请参见本主题中的详细描述用例。 您为用例提供的描述将使用与系统所用于的领域相关的一些词汇，如“销售”、“菜单”、“顾客”等。明确定义这些词汇及其关系是非常重要的，您可以借助 UML 类图来进行定义。有关更多信息，请参见 UML 类图：准则。 用例只处理系统的功能要求。诸如业务规则、服务质量要求和实现约束等其他要求必须另外表示。体系结构和内部细节也必须另外说明。有关如何定义用户需求的更多信息，请参见用户需求建模。 本主题中使用的示例与顾客可在其上从本地餐馆订餐的网站有关。
“参与者”(1) 是与您的系统进行交互的一类人、组织、设备或外部软件组件。例如，“顾客”、“餐馆”、“温度传感器”、“信用卡授权方”都是参与者。 “用例”(2) 表示一个或多个参与者为实现特定目标而执行的操作。例如，“订餐”、“更新菜单”、“处理付款”都是用例。 在用例图中，用例与执行它们的参与者相关联 (3)。 “系统”(4) 是您开发的任何成果。系统可以是小型软件组件，其中的参与者只是其他软件组件；系统也可以是完整的应用程序；系统还可以是部署在多台计算机和设备上的大型分布式应用程序套件。例如，“订餐网站”、“送餐业务”、“网站版本 2”都是子系统。 用例图可以显示系统或其子系统支持的用例。 主题内容 绘制用例图的基本步骤 绘制参与者和用例 详细描述用例 结构化用例 使用子系统边界 绘制用例图的基本步骤