meteorWJ's Home—Floating clound

 用例名称：修改密码  UC6003范围：系统管理 主要参与者： 普通用户前置条件： 该用户必须为本银行的用户，并且选择密码修改服务。主成功场景（或基本流程）：1． 普通用户进入系统管理，选择修改密码服务2． 用户根据提示输入旧的系统密码和新的系统密码。3． 用户提交操作结果。4． 系统验证用户输入的旧密码的正确性和新密码的安全性。5． 系统

用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。用例的使用在RUP中被推崇备至，整个RUP流程都被称作是"用例驱动"(Use-Case Driven)的，各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件，

图4.1 数据流图图元 接口：用直角矩形表示。这里接口可以是与其它信息系统的接口，也可以是角色（人机接口）。l         进程：一般用椭圆表示，但Visio中用圆角矩形表示，可能是考虑椭圆中可以容纳的字比较少的原因。数据流图中的矩形一般表示一个功能模块或一个过程，对应一个或一组动作。l         数据存储：用右边开口的矩形表示，表示数据库中存储的对象。另外在数据流图中，如果一个

用例图示例 定义系统边界可确定系统内部和外部之间的界限。 主角代表外部对象所扮演的角色。一个对象可以扮演若干角色，因此可由若干主角来代表。 通信关系用于阐明用例中主角的参与情况。 用例是主角通过系统完成一个过程时出现的一组事件。通常，用例是较大的过程，而不是单个步骤或事务。 类静态结构图示例

本文除了还会介绍一个结构型的Composite模式之外，还会有两个行为模式登场。实际上在前面的内容中，我们已经接触到行为模式了：Observer和Command就是两个典型的行为模式。行为模式更多的注重于算法和对象建间职责的分配，也就是说，它会更多的关注于这个模式系统之类的各对象协作间的语义，以及在对象间进行通讯的流控制。Composite模式 毫无疑问的，AWT中的Component-Conta

UML 活动图记录单个操作或方法的逻辑、单个用例或商业过程的逻辑流程。在很多方面，活动图是结构化开发中流程图和数据流程图 (DFD) 的面向对象等同体。本提示改编自 The Object Primer 2nd Edition 的第 6 章。 　图 1 中的活动图描述了大学新生第一次将如何办理入学的商业逻辑。 实心圆表示活动图的起点，实际上是一个占位符，带边框的实心圆表示终点

在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。我们在日常生活中也经常和ATM打交道。本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。 　　　　5.1用例图 　　　　参与者"银行储户"和ATM机。简化后的ATM机仅有取款、存款及其余功能。其余功能不做详细说明。500){this.resized=

自从1997年正式发布UML以后，大量商用UML建模CASE工具粉墨登场。这样为我们提供了许多的选择，同时也要求我们在选择正确的UML建模工具以更好地适应我们业务和软件应用程序开发需求，达到最好的投资回报率（ROI）方面做大量的调查。在这篇文章中，我们将比较两款CASE工具的UML建模能力、双向工程特性和项目生命周期支持：Sparx Systems的Enterprise Architect(EA)

1.研发模式    媒体采访描述：“关于创新机制，李博士提到，在Google有个「点子库」，每个人都可以抛出新点子，让大家「用脚」投票，即让认同且愿意加入开发的人很快聚集，并一起落实这个点子。因此一个可行的新点子，从发想到完成只需六个月，而且常常两三人就能完成；反之，不可行的点子，大家也会提供建议，因此不会有无谓的浪费。此外，Google让每人享有20%的时间，做自己想到的点子，一旦成熟，就可

定义系统边界可确定系统内部和外部之间的界限。 主角代表外部对象所扮演的角色。一个对象可以扮演若干角色，因此可由若干主角来代表。 通信关系用于阐明用例中主角的参与情况。 用例是主角通过系统完成一个过程时出现的一组事件。通常，用例是较大的过程，而不是单个步骤或事务。 类静态结构图示例 要将特性、操作和

类之间的关系  UML把类之间的关系分为以下5种.  ● 关联：类A与类B的实例之间存在特定的对应关系  ● 依赖：类A访问类B提供的服务  ● 聚集：类A为整体类，类B为局部类，类A的对象由类B的对象组合而成  ● 泛化：类A继承类B  ● 实现：类A实现了B接口  关联（Association）  关联指的是类之间的特定对应关系，在UML中用带实线的箭头表示。按

　下面这个表格简要介绍了常用的UML符号和关系。要了解有关UML概念和各种面向对象术语的详细说明，请参见后面的参考资源。、                     

   Unified Modeling Language (UML)又称统一建模语言或标准建模语言,是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。      面向对象的分析与设计(OOA＆D，OOAD)方法的发展在80年代末至90年代中出现了一个高潮，UML是这个高潮的产物。它不仅统

一、问题的提出随着网络技术教育应用的深入发展，学习资源、学习系统的规划、复杂度也日益增加，其技术手段、设计思想、系统体系结构都将发生深刻的变化，从而对学习资源、学习系统的设计与开发提出了新的要求。现代的主流软件工程技术，主张采用模型驱动的方法。模型是现实系统的一个抽象，也是对现实世界的简化。模型是现实系统的一个抽象，也是对现实世界的简化。科学研究的绝大部分工作就是对问题进行形式化描述和建立模型

  Agile 敏捷建模思想

本文讨论的是一种UML图——交互图（Interaction Diagram）。交互图描述的是一组对象之间的交互过程，或者说，这里我们实际上要回答这样一个问题：“方法调用过程在UML中怎样表示？”UML交互图本文将通过一个非常简单的交易系统来说明UML交互图。这个系统包含六个Java类。从前面几篇文章中，我们已经知道UML类图是分析Java程序结构的有效方法，图一显示了这个交易和支付系统的类图。为了

图的目的组件图的主要目的是显示系统组件间的结构关系。在 UML 1.1 中，一个组件表现了实施项目，如文件和可运行的程序。不幸地，这与组件这个术语更为普遍的用法、指象COM组件这样的东西相冲突。随着时间的推移及UML的连续版本发布， UML 组件已经失去了最初的绝大部分含义。UML 2 正式改变了组件概念的本质意思；在 UML 2 中，组件被认为是独立的，在一个系统或子系统中的封装单位，提供一

      简介：领域模型是OO分析中最重要和经典的模型。它阐述了领域中的重要概念。本次将介绍有关领域模型的基本技术。    领域模型：是对领域内的概念类或现实世界中对象的可视化表示[MO95,Fowler96]。领域模型也称为概念模型，领域对象模型和分析对象模型。   UP对领域模型的定义是，可以在业务建模科目中创建的制品之一。更准确地讲，UP领域模型是UP业务对对象模型（BOM）的

     上一次写一点有关领域模型的东西，今天来写点系统顺序图的知识吧。。。      Ready？GO！      简介：系统顺序图是为阐述与所讨论系统相关的输入和输出事件而快速、简单地创建的制品。它们是操作契约和对象设计的输入。      顺序图示例：              系统顺序图（SSD）：用于用例的一个特定场景，外部参与者产生的事件，其顺序和系统之内的事件。所有系统被视为黑盒，

   最近开始学习UML,在中看到有关于其他需求的部分,觉得这点还是比较容易被忽略的.在这里, 提出来和大家共享,呵呵...Ready？GO！    第七章—其他需求     除了用例之外，还有一些其他的重要的UP需求制品，这里谈到的是一些次要的需求主题而不是OOA/D。这些内容与案例研究的关系密切，能提供更为完整的需求。     其他需求制品包括：                        

UML状态图描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常我们创建一个UML状态图是为了以下的研究目的： 研究类、角色、子系统、或组件的复杂行为。 建模实时系统。   指南∶ 概要 当行为的改变和状态有关时才创建状态图。 把初始状态放置在左上角。 把最终状态放置在右下角。 状态指南 状态名称要简单但应具有描述性。 避免"黑洞"状