电子商务系统的分析与设计-第2章UML.ppt

第2章 统一建模语言UML,目录,UML概述,常用的UML元素分析,UML的通用机制,小结,UML的扩展机制,UML面向对象的分析设计工具,UML Unified Modeling Language 统一建模语言 1996年，由Rational公司的G.Booch、J.Rumbaugh、I.Jacobson共同提出，并由若干大公司共同推荐，为OMG所采纳，进而成为了可视化建模的事实标准。 目前最新版本2.1.2,UML概述,UML展现了一系列最佳工程实践，这些最佳实践表现在对大规模、复杂系统进行建模方面非常有效。 UML最适于数据建模，业务建模，对象建模，组件建模。 UML作为一种模型语言，它使开发人员专注于建立产品的模型和结构。当模型建立之后，模型可以被UML工具转化成指定的程序语言代码。,UML的特点和应用,特点 一种可视化的语言 一种可用于详细描述的语言 精确 无歧义 完整 一种构造语言 正向工程 逆向工程 一种文档化的语言 主要应用于软件系统的分析、设计工作，也可应用于非软件领域,？什么是模型,模型就是对一个对象或物体的简化表示。如，地球仪就是一个模型，它是对地球的简化表示。我们可以用模型来表示现实领域中的业务，也可以用模型表示软件领域中的软件组成和结构。日常生活中，常见的模型有很多，如图1所示。 下面按用途对模型进行命名的有： 交通模型：道路交通图、交通标志 建筑模型：建筑物模型、沙盘、公司总部的3D复制品,什么是模型,图1 常见的模型,数据分析模型：条形图、饼状图 设计模型：建筑平面图、管线图、电路板设计图 上面这些模型是用图形符号对现实世界中某个事物的模仿或仿真。 在电子商务系统开发工程中，模型主要用来描述问题域和软件域。问题域主要包括业务、业务规则、业务流程、工作流程；软件域主要包括软件组成、软件结构、软件部署等。,什么是模型,系统建模的重要性引子,下面先请看3个“小短片”！ 轻松一下,引子1盖不好的屋顶？,有人要挣钱没?,有,有,这是我的房子,少个屋顶盖,材料我都准备好了,给我安上就好.能做的来么?,放心吧,没问题!,3天过去了,你们! 都怎么做的?!,一个屋顶搞得坑坑洼洼,你们到底做过没,会不会做啊,这个, 哪里是放上去那么简单!要想好过程,有个工序,不是光有力气就可以的.,之前没做过,不过这个有把子力气不是就可以?,这个,这个我也没想到啊,不就是把屋顶放上去么,质量不合格 钱,不给了!,干这么辛苦竟然没有钱!怎么回家过年啊,引子2-HR的烦恼,气死人了！,Phil,Maria,她嫁给了一个姓 Starlight 的人吗？,只能在婚姻状况 改变时才能更改姓名,我从没想过谁会莫名 其妙地更改自己的姓名,这并不是我的错！我从来不知 道你需要处理这种情况,我现在正 忙着做一个新的性能检测系统 ，并且还要处理职员系统 的一些需求变更请求,我还有别的事。 我只可能在月底前修改好， 一周内不行，很抱歉。 下次若有类似情况， 请早一些告诉我并把它们写下来,M a r i a，你要明白，这不是我的过错 如果你一开始就告诉我，你要能随时改变某个人 的名字，那这些都不会发生,引子3如此客户！,信息系统开发小组的 新管理员Cynthia,“我已经明白这个项目的重要性了，Gerhard”Cynthia说道。“但在我制定计划前，我们必须收集一些系统的需求。”,信息系统开发小组的新管理员Cynthia,“你的意思是什么？我不是刚告诉你我的需求了吗？”,“实际上，你只说明了整个项目的概念与目标”，,“这些高层次的业务需求并不能为我们提供足够的详细信息以确定究竟要开发什么样的软件，以及需要多长时间。我需要一些分析人员与一些知道系统使用要求的化学专家进行讨论，然后才能真正明白达到业务目标所需的各种功能和用户的要求。我们甚至并不需要开发一个新的软件系统，这样可节省许多钱。”,“那些化学专家都非常忙 ，他们没有时间与你们详细讨论各种细节，你不能让你的手下的人说明吗？”,“如果我们只是凭空猜想用户要求，结果不会令人满意。我们只是软件开发人员，而并非化学专家。我们并不能真正明白化学专家们需要这个化学制品跟踪系统做些什么。我曾经尝试过，未真正明白这些问题就匆忙开始编码，结果没有人对产品满意。”,“行了，行了，我们没有那么多时间，我来告诉你需求，请马上开始开发系统。随时将你们的进展情况告诉我。”,构建一个软件系统最困难的部分是确定构建什么。其他部分工作不会像这部分工作一样，在出错之后会如此严重地影响随后实现的系统，并且在以后修补竟会如此的困难。 Fred Brooks,为什么建模,开发电子商务系统包括两个方面工作： 第一是对业务和业务规则的理解和表示； 第二是规划和设计电子商务系统。,由于业务规模和复杂度不断增加，软件的规模和复杂度也不断增长，人们对业务的理解、对软件的设计和构造越来越困难，只有借助UML这种建模语言来表示和理解业务； 借助UML语言来设计和构造软件系统，通过UML来表示和展现系统组成和交互。 在软件开发活动中，UML主要用于两个方面的建模：对业务建模和对要构造的软件建模。,为什么建模,为什么建模,1对业务建模 业务建模的目的是理解业务内容和业务过程。你对自己的业务过程建模，不仅是为了理解业务的内容中规定了要做什么，业务是如何进行的，同样也是为了识别业务的变更对业务造成的影响。 对业务建模，有助于你发现业务的优缺点，找出需要改进和优化的地方，在某些情况下还可以对几个可选的业务过程进行仿真。,2对软件建模 软件建模的目的是用UML表示软件的体系和组成，方便软件设计人员理解和修改软件方案，确保软件设计和计划能正确地实现，同时，一旦设计和计划需要修改时，修改后的软件系统，同样经受得起时间的检验。例如，当在一个软件系统中增加一个组件时，你要保证系统不会因为增加了这个组件而崩溃。,为什么建模,1.建模的目标,通过对业务和软件系统建模，以实现下面4个目标： 对业务和软件进行可视化，便于对业务和软件系统的理解和交流。 详细说明系统的组成、结构和系统交互的行为。便于开发人员对系统的宏观理解。 用模型的方式为系统提供一个模板，开发人员依据该模板构造软件系统。 将计划和决策文档化。,2建模的原则,仅当需要时，才为业务或软件系统构建模型 按照实际情况或按我们需要的样式，对业务或软件系统进行建模。 依据解决方案，来构造需要的模型。 最好用一组相对独立的模型，从不同的侧面，描述重要的业务或软件系统。,常用的UML元素分析,视图（view） UML是用模型来描述系统的结构或静态特征以及行为或动态特征的，它从不同的视角为系统的架构建模形成系统的不同视图。 视图是表达系统某一方面特征的UML建模构件的子集，在每一类视图中可使用一种或两种特定的图（diagram）来可视化地表示视图中的各种概念。,UML的构成,用例视图（Use Case diagram） 静态视图（Static diagram） 类图 Class diagram 对象图 Object diagram 包图 Package diagram 状态视图 Statechart diagram 活动视图 Activity diagram 交互视图 （Interactive diagram） 顺序图 Sequence diagram 协作图 Cooperation diagram 实现视图（Implementation diagram） 构件图 Component Diagram 部署图 Deployment Diagram,描述系统的动态模型和组成对象间的交互关系,描述系统组成元素的静态结构,描述对象间的交互关系,描述系统的物理组成单元,模型管理视图 模型管理视图是对模型自身组织进行的建模，是由自身的一系列模型元素（如类、状态机和用例）构成的包所组成的模型。模型是从某一观点以一定的精确程度对系统所进行的完整描述。 从不同的视角出发，对同一系统可能会建立多个模型，例如有系统分析模型和系统设计模型等等。模型是一种特殊的包。一个包 (package) 还可以包含其他的包。 整个系统的静态模型实际上可看成是系统最大的包，它直接或间接包含了模型中的所有元素内容。,模型管理视图,模型管理视图,图2 UML语言体系,1.构造元素 构造元素包括基本元素、关系和图。这3种元素代表了软件系统或业务系统中的某个事物或事物间的关系。 2.规则 构造元素应该具有命名、范围、可见性、完整性和执行等属性。规则是对软件系统或业务系统中的某些事物的约束或规定。 3.公共机制 公共机制包括详述、修饰、通用划分、扩展机制。公共机制指适用于软件系统或业务系统中每个事物的方法或规则。,模型元素,元素是对模型中最具有代表性的成分的抽象，关系描述了 元素之间如何彼此关联、相互依赖或作用的。正是关系把 构成系统的诸多元素结合成一个有机的整体。 元素 元素是UML模型中面向对象基本的模块，它们在模型中属于静态部分。元素作为对模型中最具有代表性的成分的抽象，在UML中，定义了四种基本的面向对象的元素，分别是结构元素、行为元素、分组元素和注释元素等。,UML构造元素基本元素,UML构造元素基本元素,结构元素 模型的静态部分：用例、类、接口、协作、组件和节点等。 行为元素 模型的动态部分：交互和状态机 分组元素 模型的组织部分：包 注释元素 模型的解释部分：注解,关系 UML模型是由各种事物以及这些事物之间的各种关系构成的。关系是指支配、协调各种模型元素存在并相互使用的规则。 UML中主要包含四种关系，分别是依赖、关联、泛化和实现。,UML构造元素关系,UML基本元素 类(Class),表示由三部分构成 名称必须包含 其余可省略或陆续添加 可说明属性及操作的可见性 可说明属性的类型 可说明操作的参数、返回值,UML基本元素 对象(Object),表示由两部分组成 没有操作 名称必须包含 名称带下划线 名称后可跟类名 其余可省略或陆续添加 可说明属性的类型,UML基本元素 用例(Use Case)和参与者(Actor),参与者 存在于作为研究对象的系统之外的实体 可以为人、机构、设备、系统等 利用人形表示 通常仅包含其名称,用例 对一组动作序列的描述，系统执行这些动作将产生一个对特定参与者有价值而且可观察的结果 使用实线椭圆 通常仅包含其名称,UML基本元素 关系,依赖关系（dependency）,代表：使用关系 说明一个事物规格说明的变化可能影响到使用它的另一个事物 箭头指向被依赖的事物,泛化关系（generalization）,指一般事物（称为超类或父类）和该事物的较为特殊的种类（称为子类）之间的关系 一个类可以有0个、1个或多个父类 没有父类且最少有一个子类的类称为根类或基类 没有子类的类称为叶子类 箭头指向被继承的类,关联关系（association）,代表一种结构关系 类型 自关联 二元关联 关联可以有一个名称,聚集、聚合（Aggregation） 一种特殊的关联关系,用于表示整体与部分的关系 以菱形表示 可进一步细分为： 普通聚集，共享聚集（Shared Aggregation） 整体与部分可以单独存在 以空心菱形表示 组合（Composition） 整体拥有部分，部分与整体共存 以实心菱形表示,类及类之间的关系,自关联,同时存在两种关系,依赖 关系,泛化 关系,多元 关联,类及类之间的关系,类图,用于描述类与类之间的静态关系 类图主要由类及它们之间的关系构成，此外，还可以包含接口、包等元素，也可包括对象等实例,对象图（Object Diagram）,形式与类图相似 对象之间的连接使用“链”（Link）,包图（Package Diagram）,目的：将复杂的大系统拆分为若干小系统 包：将若干元素集合成一个更高层次的单位，形成一个低耦合、高内聚的元素集合，将其称为包。 包中的元素也具有可见性。 包图利用类似于文件夹的符号表示包。 包图主要描述包之间的包含及依赖关系。,用例图（Use Case Diagram）,要素 参与者 用例 关系 用例图描述了 谁将是系统的使用者 使用者希望系统提供什么服务（功能） 使用者与系统之间的交互（参与者与用例之间的关系） 关联关系（association） 系统所提供的服务（用例之间的关系） 包含关系（include） 延伸关系（extend） 泛化关系（generalize）,用例之间存在的三种可能的关系,包含关系（include） 表示基础用例（客户用例）在其内部说明的某一位置显式地合并了另一个用例的行为 用途 用例的复用 用例的简化 延伸关系（extend） 基础用例在由延伸用例间接地说明的一个位置上，隐式地合并了另一个用例的行为 特点：即使没有扩展用例，基础用例本身也是完整的 用途 把新的行为插入到已有用例中 把复杂的可选的处理从基本的必须的处理中分离出来 泛化关系（generalize） 与类的泛化关系相似 用途 先给出一个概念性的用例，再给出其实现用例,参与者与用例之间的关联关系,用例之间的关系,用例图的主要用途,分析阶段 帮助识别系统的相关主体 帮助明确并逐步细化系统功能需求 是绘制其它图的出发点 实现阶段 是编制测试用例的基础 实施阶段 是制定培训、维护计划的依据,状态图（Statechart Diagram）,状态图是对类的一种补充描述，它展示了此类对象所具有的可能的状态以及某些事件发生时其状态的转移情况。 在状态图中，状态由圆角矩形表示。状态的改变称作转移，状态转移由箭头表示，箭头旁可以标出转移发生的条件。状态转移可以伴随有某个动作，它表明当转移发生时系统要做什么。,状态图示例,状态图示例,活动图（Activity Diagram）,活动图描述系统中各种活动的执行顺序，通常用于描述一个操作中所要进行的各项活动的执行流程。同时，它也常被用来描述一个用例的处理流程，或者某种交互流程。 活动图由一些活动组成，图中同时包括了对这些活动的说明。当一个活动执行完毕之后，控制将沿着控制转移箭头转向下一个活动。活动图中还可以方便地描述控制转移的条件以及并行执行等要求。,活动图示例,加水到容器中,将咖啡放到 过滤器中,点燃咖啡炉,取出咖啡杯,把过滤器放 到咖啡炉上,冲调咖啡,倒咖啡,找饮料,取一听 可口可乐,喝饮料,人,找到可口可乐,没有可口可乐,没有咖啡,找到咖啡,熄灭咖啡炉,活动图示例,活动图的主要用途,分析阶段 辅助进行工作流分析 辅助对系统中主体行为进行分析 设计阶段 设计类的依据 最终细化到程序流程图,交互图（Interaction Diagram）,与活动图一样，用于对系统的动态特性建模 交互图强调从对象到对象的控制流 活动图强调从活动到活动的控制流 由顺序图和协作图共同构成 显示的是一个交互，由一组对象和它们之间的关系组成，包含它们之间可能传递的消息 顺序图：强调时间顺序的交互图 协作图：强调结构组织的交互图 两者在语义上是等价的,顺序图（Sequence Diagram）,要素 对象：沿X轴排列 名称 生命线 控制焦点可选，用于可视化消息的嵌套或实际计算发生时的时间 消息：沿Y轴排列 名称 参数（可选） 消息的类型 普通消息 调用,例子1：通过一个简单交易系统来说明UML交互图,要达到某个特定的目标，必然要执行一系列的方法调用。UML序列图的典型用途就是显示出方法调用过程。在UML序列图中，调用一个操作就叫做发送一个消息（Message）。,交易事务中计算累计金额的时序图,时序图有两个维度：垂直维度以发生的时间顺序显示消息/调用的序列；水平维度显示消息被发送到的对象实例,活动条可以嵌套，表示在前一方法的执行过程中，又有同一对象的另一个方法被调用.,交易事务中计算累计金额的相关的代码片断,/*属于Sale类：从lineItem的单项金额计算交易总金额，return交易总额 */ public double calcTotal( ) total=0.0; Iterator i = lineItems.iterator(); while (i.hasNext() total += (LineItem)i.next().calcTotal(); return total; /*属于LineItem类：计算当前项目的交易金额， return 交易金额*/ public double calcTotal( ) total = product.calcTotal(this); return total; /*属于Product类：计算指定数量的产品价值多少；return 金额*/ public double calcTotal ( LineItem li ) return amount * li.getQuantity( );,顺序图强调了消息的时间顺序。在画顺序图时，首先将参与交互作用的对象沿着X轴放在图的顶端，将启动交互作用的对象放在左边，将从属的对象放在右边，将这些对象发送和接收的消息按照时间增加的顺序沿着Y轴由上而下地放置。,协作图（Collaboration Diagram）,要素 对象：名称 链：连接对象之间的弧 消息 名称 参数 顺序号：以嵌套的形式反映了消息间的先后顺序,协作图示例,交互图的主要用途,分析阶段 帮助识别系统的相关主体 帮助分析业务流程 设计阶段 设计类的操作的重要依据 设计程序流程的出发点 实现阶段 是编制测试用例的重要参考,构件图,表示系统中的不同物理组件及其联系，表达的是系统代码本身的结构。,配置图,配置图描述系统中硬件和软件的物理配置情况和系统体系结构。 由节点组成，节点代表系统的硬件，组件在 节点上驻留并执行。配置图表示系统的软件 组件与硬件之间的关系，表达的是运行系统 的结构。 组件图和配置图用于建立系统的实现模型。,配置图,客户A： 个人电脑PC,客户B： 个人电脑PC,数据库服务器： VAX,服务器：02,TCP/IP协议,TCP/IP协议,DecNet协议,配置图,下图演示了 WebServer通过 HTTP协议与Client PC通信，Client PC通过USB协议与Printer通信。,UML的通用机制,1. 规格说明,在UML语言中，每个元素都用一个图形符号表示，同时，对图形符号的语义可以用详细的文字进行描述，这种对图形符号的文字描述称为规格描述,也称为详述。 如图所示,对每个用例来说,既有图形描述,也有对应的文字描述,即,详细描述。,UML的通用机制,2. 修饰 在UML的图形表示中，每一个模型元素都有一个基本符号，这个基本符号可视化地表达了模型元素最重要的信息。 用户也可以把各种修饰细节加到这个符号上以扩展其含义。这种添加修饰细节的做法可以为图中的模型元素在一些视觉上的效果上发生一些变化。,UML的通用机制,3. 通用划分 通用划分是一种保证不同抽象概念层次的机制。通常我们可以采用两种方式进行通用划分，一种是对类和对象的划分，另外一种是对接口和实现的分离。 类和对象的划分是指类是一个抽象而对象是这种抽象的一个实例化。类和对象的划分保证了实例及其抽象的划分，从而使得对一组实例对象的公共静态和动态特征无需一一管理和实现，只需要抽象成一个类，通过类的实例化实现对对象实体的管理。,UML的通用机制,3. 通用划分 接口和实现的分离是指接口声明了一个操作接口，但是却不实现其内容，而实现则表示了对该操作接口的具体实现，它负责如实地实现接口的完整语义。 由于接口是要向外公开的，而实现是需要隐藏的（用户不需要知道），这样才能应对变化。比如接口的实现有