个人博客UML建模

一、为什么要学习UMLUML是Unified Modeling Language（统一建模语言）的简称。

UML是对软件密集型系统中的制品进行可视化、详述、构造和文档化的语言。

制品{Artifact}是指软件开发过程中产生的各种各样的产物，如模型、源代码、测试用例等。

UML建模可以达到以下目的：使用模型可以更好地理解问题使用模型可以加强人员之间的沟通使用模型可以更早地发现错误或疏漏的地方使用模型可以获得设计结果模型为最后的代码提供依据二、UML的历史1997年，OMG组织（Object Management Group对象管理组织）发布了统一建模语言（Unified Modeling Language，UML）。

UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。

UML提出了一套IT专业人员期待多年的统一的标准建模符号。

通过使用UML，这些人员能够阅读和交流系统架构和设计规划--就像建筑工人多年来所使用的建筑设计图一样。

2003年，UML已经获得了业界的认同。

在所见过的专业人员的简历中，75%都声称具备UML的知识。

然而，在同绝大多数求职人员面谈之后，可以明显地看出他们并不真正了解UML。

通常地，他们将UML用作一个术语，或对UML一知半解。

大家对UML缺乏理解的这种状况，促进我撰写这篇关于UML 1.4的快速入门文章。

当阅读完本文时，您还不具备足够的知识可以在简历上声称自己掌握了UML，但是您已具有了进一步钻研该语言的良好起点。

三、UML的特点UML的主要特点包括：统一的标准面向对象。

UML是支持面向对象软件开发的建模语言。

可视化、表现能力强独立于过程，UML不依赖于特定的软件开发过程。

概念明确，建模表示法简洁，图形结构清晰，容易掌握和使用。

四、UML中的视图UML中的视图包括用例视图（Use Case View）、逻辑视图（Logical View）、实现视图（Implementation View）、进程视图（Process View）、部署视图（Deployment View）等，这5个视图被称作”4+1”视图.如下图所示：逻辑视图。

UML建模的要点总结第一篇：UML建模的要点总结UML建模的要点总结预备知识：一、UML的特性与发展现状UML是一种Language(语言)UML是一种Modeling(建模)Language UML是Unified(统一)Modeling Language1、已进入全面应用阶段的事实标准2、应用领域正在逐渐扩展，包括嵌入式系统建模、业务建模、流程建模等多个领域3、成为“产生式编程”的重要支持技术：MDA、可执行UML等二、建模的目的与原则1、帮助我们按照实际情况或按我们需要的样式对系统进行可视化;提供一种详细说明系统的结构或行为的方法;给出一个指导系统构造的模板;对我们所做出的决策进行文档化。

2、仅当需要模型时，才构建它。

3、选择要创建什么模型对如何动手解决问题和如何形成解决方案有着意义深远的影响;每一种模型可以在不同的精度级别上表示;最好的模型是与现实相联系的;单个模型是不充分的。

对每个重要的系统最好用一组几乎独立的模型去处理。

三、谁应该建模1、业务建模：以领域专家为主，需求分析人员是主力，系统分析员、架构师可参与2、需求模型：以需求分析人员为主，系统分析员是主力，领域专家提供指导，架构师和资深开发人员参与3、设计模型：高层设计模型以架构师为主，系统分析员从需求方面提供支持，资深开发人员从技术实现方面提供支持。

详细设计模型则以资深开发人员为主，架构师提供指导。

4、实现模型：以资深开发人员(设计人员)为主，架构师提供总体指导。

5、数据库模型：以数据库开发人员为主，架构师提供指导，资深开发人员(设计人员)予以配合。

正式开始UML组成，三部分(构造块、规则、公共机制)，关系如下图所示：一、构造块1、构造块是对模型中最具有代表性的成分的抽象建模元素：UML中的名词，它是模型基本物理元素。

行为元素：UML中的动词，它是模型中的动态部分，是一种跨越时间、空间的行为。

分组元素：UML中的容器，用来组织模型，使模型更加的结构化。

uml软件建模知识点总结一、UML概述UML，全称为Unified Modeling Language，即统一建模语言，是一种为面向对象系统设计和分析而开发的通用标准建模语言。

UML作为一种建模语言，具有多样的元素和关系，可以被用来描述和分析系统的结构和行为。

UML最初是由Rumbaugh、Booch和Jacobson 等人提出的，经过了一系列的发展，已经成为了全球范围内最流行的软件建模语言。

二、UML的主要图表UML主要有以下几种图表：用例图、类图、时序图、活动图、状态图、协作图、构件图等。

1. 用例图（Use Case Diagram）用例图用于描述系统的功能需求，它展示了系统的功能模块和用户之间的交互关系。

在用例图中，用户被表示为参与者(actor)，而系统的功能则被表示为用例(use case)。

用例图可以帮助软件开发团队更好地理解系统需求，并且为团队成员之间的沟通提供了一个共享的模型。

2. 类图（Class Diagram）类图用于描述系统的静态结构，展示了系统中各个类的属性和方法之间的关系。

在类图中，类被表示为一个矩形，包括了类名和类的属性和方法。

类与类之间的关系主要有：关联、依赖、一般化、实现等。

3. 时序图（Sequence Diagram）时序图用于描述系统中的交互行为，展示了类之间的消息传递过程。

在时序图中，元素主要有对象、生命线、消息和激活。

时序图帮助开发团队更好地理解系统的交互过程，有助于对系统的动态行为进行分析和设计。

4. 活动图（Activity Diagram）活动图用于描述系统的工作流程，展示了系统中各活动之间的控制流。

在活动图中，元素主要有开始节点、流程节点、决策节点、合并节点、结束节点等。

活动图可以帮助开发团队更好地理解系统的流程，有助于对系统的业务逻辑进行分析和设计。

5. 状态图（State Diagram）状态图用于描述系统的状态转移过程，展示了系统中各状态之间的转移关系。

基于UML的用例图模型创建引言UML（统一建模语言）是一种用于软件开发的标准化的建模语言，它包括了一系列图形符号和符号的标准定义，用于描述系统的结构和行为。

用例图作为UML中的一个重要模型之一，用于描述系统的功能需求，是软件开发中的重要工具之一。

本文将介绍基于UML的用例图模型创建的过程，包括用例的识别、用例图的绘制和用例之间的关系等内容。

第一部分：用例的识别用例是系统对外的一种功能需求的描述，通常由用户或其他外部系统发起的事件来触发。

在创建用例图模型时，首先需要明确系统要实现的功能，并对这些功能进行分类和识别。

用例的识别可以通过以下步骤来进行：1. 确定系统的边界：确定系统与外部世界之间的边界，了解系统的范围和功能。

2. 收集需求：通过与系统的用户、业务分析师等相关人员进行沟通，收集系统的功能需求，明确系统需要实现的功能。

3. 识别用例：根据需求收集的信息，将系统的功能拆分成不同的用例，每个用例表示系统的一个功能模块或一个用户任务。

4. 细化用例：对于较复杂的用例，可以进一步分解成子用例，以便更好地描述系统的功能。

通过以上步骤的识别工作，可以清晰地了解系统的功能需求，为进一步创建用例图模型做好准备。

第二部分：用例图的绘制在对系统的功能需求进行了识别之后，接下来可以开始绘制用例图模型。

用例图由用例、参与者和它们之间的关系组成，它可以清晰地展示系统的功能和用户角色之间的交互。

用例图的绘制可以遵循以下步骤：1. 确定参与者：参与者是指使用系统的人、组织或其他外部系统，它们与系统之间有直接的交互。

根据用例的识别结果，确定系统中的参与者，并将它们表示在用例图中。

3. 连接参与者和用例：用实线将参与者和用例连接起来，表示参与者与用例之间有交互。

参与者可以触发用例的执行，也可以是用例的执行者。

4. 添加关系：在用例图中，用例之间还可以有关联、泛化、包含和扩展等关系。

根据系统的功能需求，添加相应的关系来描述用例之间的逻辑关系。

2010——2011学年第一学期信息技术学院《软件系统建模与UML》综合设计实验***系统的UML建模班级学号姓名任课教师2010年12月30日目录第1章系统需求 (2)第2章需求分析 (4)2.1识别参与者 (4)2.2识别用例 (5)2.3用例的事件流描述 (11)第3章静态结构模型 (16)3.1定义系统对象 (16)3.2定义用户界面类 (16)3.3建立类图 (16)第4章动态行为模型 (19)4.1创建系统顺序图（协作图） (19)4.2创建系统的状态图 (19)4.3创建系统的活动图 (29)第5章数据库模型 (31)第6章物理模型 (32)& 1创建系统组件图 (32)& 2创建系统部署图 (33)第1章系统需求系统概述Blog是一种让编写者可以表达自己意见、发表自己的看法以及见闻的方式。

系统目标是使好友之间有一个交流沟通的平台，通过博客可以互相了解彼此的生活状况，系统拥有发布日志，心情，照片，留言评论等功能。

系统功能分析本Blog系统将完成以下功能：＞网站首页功能＞用户的注册、登录和登岀＞个人消息中心管理功能＞照片管理功能＞相册分类管理功能＞文章管理功能＞文章分组管理功能＞心情管理功能＞日志，照片，心情评论管理功能＞留言板留言，回复功能＞装扮空间功能第2章需求分析2.1识别参与者参与者关系图如图2-1所示:图2-1参与者关系图游客：未注册的用户，只拥有普通浏览功能注册会员：已注册成为会员，与游客是泛化关系，拥有查看，评论，留言，回复留言评论的功能博主八博客的拥有者，与会员是泛化关系，拥有查看，评论，回复评论，对自己博客的所有的文章，心情，照片，评论留言具有管理的权限。

2.2识别用例主用例图如图2-2所示:图2・2主用例图管理留言板用例图如图2-3所示:删除留言图2-3管理留言板用例图图2-4管理文章用例图回复评论删除评论回复评论删除评论图2-5管理相册用例图图2-6管理心情用例图查看照片会员回复评论回复评论删除评论注册登录用例图如图2-7所示:图2・7注册登录用例图管理好友用例图如图2-8所示：图2・7管理好友用例图更改装扮用例图如图2-9所示：图2-9更改装扮用例图傅主更改装扮2.3用例的事件流描述2.3.1浏览博客用例描述用例名称：浏览博客用例用例描述：用户进入自己或考其他会员的博客参与者：博主，其他会员，游客前置条件：进入博客后置条件：退出博客假设条件：用户已进入网上博客基本操作流程：1、进入网上博客2、查看信息中心，文章，好友心情，相册，留言板等3、退出网上博客备选流程：点击“进入自己博客”可以进入自己博客2.3.2管理留言板用例描述用例名称：管理留言板用例用例描述：博主可以通过此用例添加、删除留言，回复留言会员可以留言，游客只能浏览参与者：博主，其他会员，游客前置条件：成功进入到留言板模块后置条件：退出留言板模块假设条件：用户已经进入网上博客基本操作流程：1、进入留言板模块2、博主：添加，删除，修改留言，回复留言3、会员：添加留言，游客只能查看3、退出留言板模块备选流程：点击导航超链接可以直接进入其他模块23.3管理文章用例描述用例名称：管理文章用例用例描述：博主可以通过此用例添加、删除、修改文章及评论、回复评论会员可以浏览文章以及进行评论，游客只能浏览参与者：博主，其他会员，游客前置条件：成功进入到文章模块后置条件：退出文章模块假设条件：用户已经进入网上博客基本操作流程：1、进入文章模块2、博主：添加，删除，修改文章，评论及回复评论3、会员：浏览文章，添加评论和回复评论，游客只能查看3、退出文章模块备选流程：点击导航超链接可以直接进入其他模块2.3.4管理相册用例描述用例名称：管理相册用例描述：博主可以通过此模块添加、删除、修改相册；添加、删除照片会员可以浏览相册，照片，以及对照片进行评论；游客只能浏览参与者：博主，其他会员，游客前置条件：进入相册模块后置条件：退出相册模块假设条件：用户已进入网上博客基本操作流程：进入相册模块游客：查看相册照片，评论，回复3、会员：查看相册照片，评论照片，回复评论4、博主：查看、添加、删除、修改相册、照片、回复评论5、退出相册模块备选流程：点击导航超链接可以直接进入其他模块23.5管理心情用例描述用例名称：管理心情用例描述：博主可以通过此用例添加、删除、修改心情，及添加、删除评论、回复评论；会员可以浏览心情，以及进行评论，回复评论，游客只进行查看参与者：博主，其他会员，游客前置条件：成功进入到心情界面后置条件：退出心情界面假设条件：用户已进入网上博客基本操作流程：1、进入心情界面2、博主添加，删除，修改心情，添加、删除评论及回复评论3、会员为心情评论或者回复评论，游客只能查看4、退出心情界面备选流程：点击导航超链接可以直接进入其他模块2.3.6管理好友用例描述用例名称：管理好友用例描述：博主可以通过此模块添加好友参与者：博主前置条件：博主已登陆自己博客后置条件：退出添加好友模块假设条件：用户已登录自己博客基本操作流程：1、进入管理好友模块2、选择要添加或者删除的好友的会员名称3、点击添加或者删除4、添加或考删除成功4、退出管理好友模块备选流程：点击导航超链接可以直接进入其他模块2.3.7查看信息中心用例描述用例名称：查看信息中心用例描述：博主可以通过此模块更改个人信息所有用户都可以通过此模块浏览博主信息参与者：博主，其他会员，游客前置条件：成功登录到个人信息模块后置条件：退出个人信息模块假设条件：用户已进入网上博客基本操作流程：1、进入个人信息模块2、所有会员：查看博主信息3、博主：更改个人信息4、退出个人信息模块备选流程：点击导航超链接可以直接进入其他模块2.3.8装扮博客用例描述用例名称：装扮博客用例描述：博主可以通过此模块更改皮肤装扮参与者：博主前置条件：博主已登陆自己博客后置条件：退出装扮模块假设条件：用户已登录自己博客基本操作流程：1、进入装扮模块2、选择喜欢的皮肤3、点击装扮，装扮成功4、退出装扮模块备选流程：点击导航超链接可以直接进入其他模块第3章静态结构模型进一步分析系统需求，发现类以及类之间的关系，确定它们的静态结构和动态行为，是面向对象⑺分析的基本任务。

1启动添加新工程安装以后就可以启动该程序。

然后，一个名叫：New Project By Approach的对话框会弹出。

选择“Empty Project”并且按下"确定"。

这里建议你不要勾选"设置为默认的做法" 复选框。

2. 选择模块在右边的“Model Explorer”框中选定“Untitled”模块。

3. 添加模块通过“Model”主菜单，或右击选定的模型，可以" Add/ Model "4.添加类图通过“Model”主菜单，或右击选定模型，可以“Add Diagram/Class Diagram”：5.设置profile通过“Model/Profile...”菜单去设置工程所需的profile。

这决定了工程所使用的规则和约定。

一定要包含"JAVA Porfile"这一项目。

6.保存工程立即就保存工程，这样在出现问题的时候，您就不会丢失信息。

从“File ”菜单，选择“Save”，并选择一个地方以保存工程。

你的StarUML 项目现在应该看起来的是这样的：7.创造图表现在，开始真正创造图表，从默认就在屏幕的左边的“Toolbox”选择“类”图标，然后左键单击diagram窗口的某处。

这样就使用通用名字创造了一个新的类。

双击，将类改名为Circle。

8.添加属性右击图中的目标，在弹出菜单中选择“Add”中的“Attribute”(被标示为绿色)，为其添加一个属性(或者域)，填入期望的名字“_radius”。

具体的数据类型，在属性面板（右下侧的窗口），由双打字，在"类型"时段。

在窗体右下边的Properties面板中，找到“Type”输入框，输入double作为_radius 属性的类型。

类的内部数据（域/属性）都是私有的，因为他们是严格由类内部使用的。

所以，在Properties面板中将_radius设置为“私有”。

§2 UML的组成与建模过程UML是第一个统一的面向对象的可视化建模语言，当今主流的CASE都支持UML。

2.1 UML的组成UML由下列5类图组成:第1类：用例图。

从用户角度描述系统功能，并指出各功能的交互者（外部实体）。

第2类：静态图。

包括类图、对象图和包图。

其中，类图描述系统中类的静态结构，不仅定义系统中的类，表示类之间的联系（如关联、依赖、聚合），而且包括类的内部架构（类的属性和操作）。

类图描述的是一种静态关系，在系统的整个生命周期内都是有效的。

对象图是类图的实例，几乎使用与类图完全相同的标识。

包图用于描述系统的分层结构，由包或类组成，表现包与包之间的关系。

第3类：行为图。

包括状态图和活动图。

其中，状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件；活动图描述用例中的活动以及活动之间的约束关系，可用于识别活动的并发性。

第4类：交互图。

包括顺序图和协作图，用于描述对象间的交互关系和动态协作关系。

顺序图强调对象之间消息发送的顺序，同时显示对象之间的交互信息。

协作图跟顺序图相似，除显示交互信息外，还显示对象之间的结构关系。

如果强调时间和顺序，则使用顺序图；如果强调上下级关系，则可使用协作图。

第5类：实现图。

包括构件图和部署图。

构件图描述软件构件之间的依赖关系，这些构件包括源代码文件、二进制文件以及可执行文件等。

部署图（配置图）显示了基于计算机系统的物理架构。

2.2 UML的基本建模过程面向对象的软件开发过程中，传统开发模式中的阶段之间的界限已不明显。

使用UML的一般思路是，首先建立软件系统的逻辑模型，然后建立相应的物理模型。

建立系统逻辑模型的过程可大致分为3步：第一步：描述需求；第二步：根据需求建立系统的静态结构；第三步：描述系统的行为。

其中，第一步和第二步可以用用例图、类图和对象图等来描述，属于UML的静态建模机制；第三步则可以用状态图、活动图、顺序图及协作图来描述，属于UML的动态建模机制。

基于UML的用例图模型创建用例图是软件开发中最常用的模型之一。

这个UML模型可以帮助开发人员和其他利益相关者更好地了解系统的用途，功能需求和用户行为。

因此，用例图是一个非常重要而且常被使用的模型。

本文将介绍如何基于UML的用例图模型创建一个系统，它将涉及到以下几个步骤：1. 确定系统的范围2. 识别主要的外部参与者3. 识别主要的用例4. 识别用例之间的关系步骤1：确定系统的范围在创建用例图之前，首先需要将系统的范围明确。

这可以通过定义系统的上下文和边界来完成。

上下文是指系统的盈利模式，而边界确定了系统要实现的功能范围和哪些参与者需要与系统进行交互。

这种方法可以确保系统开发过程中专注于最重要的功能需求。

步骤2：识别主要的外部参与者一旦系统范围被确定，下一步是确定所有与系统交互的外部参与者。

外部参与者一般是指与系统有直接关系的人员、组织或其他系统。

例如，如果我们考虑一个在线购物系统，外部参与者可能包括客户、管理员、供应商等等。

这些参与者与系统都有一定的要求和期望，并通过用例来表达这些需求。

这一步通常是用例模型中最重要的一步，因为它确定了系统的真正目的和功能。

在这一步中，我们需要识别系统中的主要用例。

每个用例都可以描述一个用户的需求，比如购物、下订单等等。

这些用例都应该基于参与者的需求进行定义。

对于我们的在线购物系统，可能包括以下用例：- 搜索商品- 添加商品到购物车- 下订单- 支付订单- 查看订单历史记录步骤4：识别用例之间的关系每个用例都描述了一些系统中的功能需求，但是它们并不是孤立的。

相反，往往有明显的关系和依赖性。

UML用例模型中的关系通常是包括泛化，依赖，包含和扩展关系。

最常见的关系包括：- 泛化(GENERALIZATION)：一般地，一个用例可以从一个更通用的用例中继承，从而表达一些更具体的需求。

- 依赖(DEPENDENCY)：一个用例可能依赖于另外一个用例来满足某些需求。

- 包含(INCLUDE)：表示在整个用例的执行过程中，需要用到其它用例的一个或多个场景。