电子商务系统设计第四章UML建模方法

《电子商务系统设计第四章UML建模方法》由会员分享，可在线阅读，更多相关《电子商务系统设计第四章UML建模方法（48页珍藏版）》请在装配图网上搜索。

1、单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,2015/7/13,,‹#›,电子商务系统设计,第四章,UML,建模方法,,4.1 UML,核心元素,一、UML的三个根本构造块,1 事物,〔1〕结构事物〔Structural things〕：,〔2〕动作事物〔Behavioral things〕,〔3〕分组事物〔Grouping things〕,〔4〕注释事物〔Annotational things〕,类：是对具有相同属性、方法、关系和语义的对象的抽象，一个类可以实现一个或多个接口。在UML中类用包括类名、属性和方法的矩形表示。,,接口：是为类或组件提供特定

2、效劳的一组操作的集合。接口描述了类或组件的对外可见的动作。在UML中接口用圆表示，在图形旁边还要标注接口的名字。,,协作：定义了交互操作。在UML中，用虚线构成的椭圆表示，椭圆中要标注协作的名字。,,用例：描述系统对一个特定角色执行的一系列动作。在UML中，用例用标注了用例名称的实线椭圆表示。,,活动类：是类对象有一个或多个进程或线程的类，在UML中，活动类和类的表示法相同，只是边框用粗线条。,,组件：是实现了一个接口集合的物理上可替换的系统局部。,,节点：是在运行时存在的一个物理元素。它代表一个可计算的资源，通常占用一些内存和具有处理能力。一个组件集合一般来说位于一个节点。,,动作事物是UM

3、L模型中的动态局部。它们是模型的动词，代表时间和空间上的动作。总共有两种主要的动作事物：,,第一种是交互〔interaction〕，它是由一组对象之间在特定上下文中，为到达特定的目的而进行的一系列消息交换而组成的动作。,,第二种是状态机〔state machine〕，状态机由一系列对象的状态组成。,,分组事物是UML模型中组织的局部，可以把它们看成是个盒子，模型可以在其中被分解。总共只有一种分组事物，称为包〔package〕。,,注释事物是UML模型的解释局部。UML中用如以下图圈出表示：,,4.1 UML,核心元素,2,图,,UML,中的图有五种类别的图,(9,种图形,),。它们是,用例图：

4、用例图,静态图：类图、对象图,行为图：状态图和活动图,交互图：合作图和序列,(,顺序,),图,实现图：部署图和组件图,(,构件图,),4.1 UML,核心元素,3 关系,关系是建模元素之间的语义〔有意义〕联系，是UML把事物联系到一起的方法。,UML中的关系类型有：,依赖,关联,泛化,实现,依赖：,是两个元素之间的关系，对一个元素〔提供者〕的改变可能影响或提供信息给其他元素〔客户〕,依赖不仅发生在类间，它们通常发生在：,l 包和包之间   l 对象和类之间,UML中表示依赖的图形是：,,在UML中有四种根本的依赖类型：,a.Usage(使用)：客户使用由提供者所提供的效劳以实现它的行为，这是

5、最普遍使用的依赖类型。       b.Abstraction〔抽象〕：表示客户和提供者之间的关系，提供者比客户更加抽象。       c.Permission〔授权〕：提供者为客户提供某种权限以访问提供者的内容，这是一种提供者控制和限制对其内容访问的方法。       d.Binding〔绑定〕：一般用于提供参数化类型〔模板〕的语言中〔如C++〕。,,关联：,,是类间的语义联系，是类实例间连接的描述。在,UML,中表示关联的图是：,,关联可以具有以下各项：,a.关联名称,关联名称是动词短语，说明源对象正在目标对象上执行的动作。,b.角色名称,说明关联中类的对象所扮演的角色。,c. 多重

6、性,多重性说明在任意时刻关系所能够涉及的对象数目，用来约束任意时刻对象的数目。,d.导航性,用关系端部的箭头显示，说明可以从源类的任何对象到目标类的一个或多个对象〔根据多重性确定的〕遍历。,,,泛化：,,一个元素是另一个元素的特例，而且它可以取代更一般的元素,,泛化是一般元素和特殊元素之间的关系，是更概括的描述和更具体的种类间的关系，适用于继承。在,UML,的表示泛化的图形是：,,,实现：,,说明和实现间的关系。在,UML,中表示实现的图形是：,,4.1 UML,核心元素,二、,UML,中建模的机制,在,UML,中存在两种建模机制：静态建模机制和动态建模机制。,,当我们在实际的应用中使用面向对

7、象的设计和分析方法时，一般遵循的步骤是：,第一步：描述需求，一般产生用例图。,第二步：根据需求建立系统的静态模型，构造系统的结构。产生：类图，对象图，组件图和部署图。,第三步：描述系统的行为。这里建立的模型或者可以执行，或者表示执行时的时序状态或交互关系。产生：状态图，活动图，顺序图和合作图。,,第一和第二步建立的模型都是静态的，称之为静态建模，第三步称之为活动建模。,4.2 UML,核心视图,一、静态视图,1,用例图,,假设,(1),，一个仓库管理系统：仓库管理员需要进行物品进仓和物品出仓的操作，物品出仓的前提是相关物品的库存必须大于一定额度。,〔1〕 组成,用例图表示处于同一个系统中参与者

8、和用例之间的关系。是一组动作序列〔包括它的变衍生物〕的描述，系统执行该动作序列来为参与者产生一个可观测的结果值。,它用来描述需求的，描述待开发系统的功能需求，本质上是用来描述用户和系统间一次交互。它是需求分析阶段(MSF中的设想阶段)的主要任务之一。,用例图分为两个局部：用例(Use Case)和执行者(Actor),,用例,(Use Case ),：,UML,中表示为一个椭圆。它有以下特点：,1.,用例捕获某些用户可见的需求，实现一个具体的用户目标。,2.,用例由执行者激活，并提供确切的值给执行者。,3.,用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。,,执行者,(Actor)

9、,：指用户在系统中所扮演的角色。用个小人表示,〔2〕 用例间的关系,用例间的关系分为两种：使用(Include)和扩展(Extend),使用：指的是用例A要用到用例B。,例如出仓，需要检查库存情况，那用例“物品出仓〞就要用到用例“显示物品的库存〞。,扩展：表示某个用例是从另外一个用例扩展而来的。,例如仓库管理员在物品进仓的时候，可以查看相关物品的库存情况。那么用例“查看物品的库存情况〞就是扩展自用例“物品进仓〞。,〔3〕 如何发现用例,一般可以采用“主谓〞结构的方式来发现用例，也就是“谁做什么〞。“谁〞就是ACTOR，“做什么〞就是用例。对于已识别的角色，通过询问以下问题就可以发现用例：,,1

10、.角色需要从系统中获得哪种功能？角色需要做什么？   2.角色需要读取，产生，删除，修改或存储系统中的某种信息吗？   3.系统中发生的事件需要通知角色吗？或者角色需要通知系统某件事件吗？这些事件(功能)能干些什么？   4.如果采用系统的新功能处理角色的日常工作是简单化了，还是提高了工作效率？   5.还有一些与当前角色可能无关的问题，也能帮助建模者发现用例。例如：        a.系统需要的输入/输出是什么信息？这些输入/输出信息是从哪里来到哪里去？        b.系统当前的这种实现方法要解决的问题是什么？(也许是用自动系统代替手工操作？),,对于假设(1)，仓库管理员就

11、是ACTOR，要进行的动作有“物品进仓〞，“物品出仓〞和“获得物品的库存情况〞，相应的用例就是这三个。,〔4〕 实例,实例,1,参与者之间的泛化关系,参与者：经理，平安主管，保安,用例：管理人事，批准预算，批准平安证书，监视周边,在参与者之间不存在泛化关系的情况下，各个参与者参与用例的情况分别是：经理参与用例管理人事和批准预算；平安主管参与用例批准平安证书；保安参与用例监视周边。由于平安主管与经理，平安主管与保安之间泛化关系的存在，意味着平安主管可以担任经理和保安的角色，就能够参与经理和保安参与的用例。这样，平安主管就可以参与全部4个用例。但经理或者保安却不能担任平安主管的角色，也就不能参与用

12、例批准平安证书。,,实例,2,用例之间扩展和包含关系,用例的上下文是：短途旅行但汽车的油缺乏以应付全部路程。那么为汽车加油的动作在旅行的每个场景(事件流)中都会出现，不加油就不会完成旅行。吃饭那么可以由司机决定是否进行，不吃饭不会影响旅行的完成。,实例,3,航空售票的用例图,参与者(actor)：clerk，监督员，信用卡效劳商，信息亭,用例(use case)： Buy tickets， Buy Subscription， Make charges， Survey sales,参与者Clerk参与(或称发起)Buy tickets和Buy Subscription 两个用例(关联关系)。这两

13、个用例的事件流都包含Make charges用例(包含关系)。,系统由：Buy tickets， Buy Subscription， Make charges， Survey sales组成。,该系统主要包含：Buy tickets， Buy Subscription， Make charges， Survey sales这几个功能。,该系统主要面向的用户(参与者)：clerk，监督员，信用卡效劳商，信息亭。,4.2 UML,核心视图,2,类图,,类是具有相同特征的对象的集合。对象是类的一个实例，是类的一个具体表现。打个比方：人是类，而张三就是对象。一个类可以有很多个实例,(,对象,),。

14、,〔1〕 类的组成,类包括这三局部：,1.名称：类的名称,2.属性：描述类的对象包含的数据。例如类“人〞。它的属性有：姓名，性别，年龄等等。,在UML 中表示属性的语法是：可见性 属性名 ：类型 = 缺省值 {约束特性}。其中常用的可见性有Public、Private和Protected三种，在UML中分别表示为“+〞、“-〞和“#〞。对于类人的姓名属性可以写成：+ 姓名：字符串型=“〞。表示姓名属性是Public的，类型是字符串型的，缺省值为空串。,3.方法(操作)：是类的功能，只能作用到该类的对象上，定义了对象之间可能的交互。,在UML中表示方法的语法为：可见性 操作名 (参数表) ：返回

15、类型 {约束特性}。对于类人的吸气方法，我们可以写成：+ 吸气(氧气)：二氧化碳。表示吸气方法是公共的，需要氧气做参数，返回的类型是二氧化碳。,〔2〕 类之间的关系,1.,关联,关联用于描述类与类之间的连接。由于对象是类的实例，因此，类和类之间的关联也就是对象和对象之间的关联，类和类之间有多种连接方式每种连接方式各不相同(语义的连接)，但外部表现形式相类似，故我们称之为关联。关联关系之间一般都是双向的，关联的双方都能够互相通信；反过来说，如果某两个类能够互相通信或者y一方能感知另一方，那么这两个类之间就存在关联关系。描述这种关系常用的子句是“彼此知道，互相连接〞。,关联有,0,或,1,对多，多

16、对多等几种。例如班级,(Class),类和学生,(Student),类，他们之间就是,1,对多的关系。,关联类是起关联作用的类，是通过一根虚线与关联连接。例如每个"保险单"属于一个"客户",而"客户"可以签定多个"保险单"。除了这个关联外，还有另外两个关联,分别是每个"保险单"包含假设干个"保险单上的工程",而每个"保险单上的工程"涉及单一的"保险类别"。,聚合：一种特殊形式的关联。聚合表示类之间的关系是整体与局部的关系。比方计算跟打印机的关系，一台完整的计算机可以包括打印机，但是没有打印机，计算机也可以运行。,,组合：另一种特殊形式的关联。组合也表示类之间的关系是整体与局部的关系，但整体拥有

17、各局部，局部与整体共存，如局部不存在了，整体也就不完整。例如计算机跟CPU的关系，如果没有了CPU，那么计算机就没有方法运行。,,在UML中，聚合表示为空心菱形，组合表示为实心菱形。,2.,继承,,定义了一般元素和特殊元素之间的分类关系。在,UML,中，继承表示为一端是空心三角形的实线：,例如人，人是共性,(,一般,),的元素，而男人和女人就是特殊的元素。我们可以说：男人继承自人，女人也继承自人，而漂亮女人继承自女人。,3.,依赖,有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，那么称元素Y依赖(Dependency)于元素X。在类中，依赖由各种原因引起，如：一个类

18、向另一个类发送消息；一个类是另一个类的数据成员；一个类是另一个类的某个操作参数。,,UML中依赖表示为：虚线加箭头,,〔3〕 类图,它是描述类和类之间的静态关系，是用来记录系统的静态结构。也就是指出系统包括哪些类，它们是如何关联的，但不包括为实现特定的行为而进行的交互。,它是定义其它图的根底。,在UML中通常是用个矩形方框表示：,矩形顶部：名称，类名称首字母大写；如保险根底数据模型中主题编号描述为Pnn,nn表示从01开始的两位数字编号，如P01。,矩形中部：属性，一般用小写字母；,矩形底部：方法，一般用小写字母；,它通常包含：,1.类      2.接口      3.协作      

19、4.类间的关系,〔4〕 如何发现类,标识正确的类是设计面向对象系统的主要工作，找出系统中的类的方法有：,1.名词/动词分析,是一种非常简单的方法。,它首先对系统需求进行简明一致的陈述，然后将名词和名词短语用下划线表示出来，即标识出代表事物的词和短语。这样就产生一个候选类列表，从中筛选整理后获得系统的初始类列表。过程是：,a.找知名词或名词短语，这些是候选类或属性       b.找出动词或动词短语，这些是候选职责或操作       c.分析收集到的信息，得到初始类列表,对于假设(1)中的物品出仓，物品和仓库就是类。,2.CRC卡:是一种有力的和有趣的脑力风暴技术。它的方法是：,a.把问题域

20、中重要事物书写在便笺上,b.每个便笺具有三个分栏的：, 类名(在顶端)           类的职责(在左边)           类的协同者，帮助实现每个功能(在卡片的右边),它经历的过程是一种脑力风暴的过程：,a.要求团队成员命名运转在业务领域的“事物〞，把它们书写在便笺上,b.要求团队陈述该事物的职责，把他们记录在便笺的职责分栏上,c.要求团队识别可能一起工作的类，并且在他们之间连线或者把这些记录在每个便笺的协同者分栏中,,对于假设,(1),，建立的类图是：,该图意在表示类和关系的用法，并不完整〔不包括产品和订单细目局部，也没有表达库存检查局部〕.另外,GO是出仓单的简写.,4

21、.2 UML,核心视图,二、动态视图,1,序列图,,〔1〕 定义,是一种动态建模方法，用来描述对象之间动态的交互关系，着重表达对象间消息传递的时间顺序。,〔2〕 组成,UML中序列图中存在两根轴，分别是时间轴(垂直方向)和对象轴(水平方向)；,顺序图中的对象用一个带有垂直虚线的矩形框表示，并标有对象名和类名。垂直虚线是对象的生命线，用于表示在某段时间内对象是存在的。对象间的通信通过在对象的生命线间画消息来表示。消息的箭头指明消息的类型。,顺序图中的消息可以是信号(Signal)、操作调用。当收到消息时，接收对象立即开始执行活动，即对象被激活了。,通过在对象生命线上显示一个细长矩形框来表示激活。

22、消息可以用消息名及参数来标识。,上图表示aManager(仓库管理员)建立出货单,然后再进行库存检查的过程。当然,库存检查是在增加产品之后由产品对象调用库存检查,但是此处设计不包括产品局部,为了表达效果,改用订单对象直接调用库存检查。,2,活动图,,〔1〕 定义,UML活动图是一种特殊的状态图，记录了单个操作或方法的逻辑，单个用户案例，或者单个业务流程的逻辑。表示一个程序或工作流。工作流是被活动图所建模的过程的例子。活动图通常出现在设计的前期，即在所有实现决定前出现，特别是在对象被指定执行所有的活动前，其状态代表活动的执行，就像一个计算机或真实世界不间断的操作，而转换由状态内活动的完成来触发〔

23、假设有约束条件，可能有几个可能不同的出口〕。,,活动图是强调计算过程中顺序的和并发步骤的状态机。,〔2〕 组成,状态：来表示某个活动或动作，分为“动作状态〞，“状态〞，“初始状态〞，“最终状态〞；,泳道：用来表示活动图中的责任，是个矩形,3.,控制流：表示从一个状态到另一个状态的变化。,,。是活动图中活动的,分组，每个组代表活动职责的一些有意义的局部；,3,状态图,,,用来描述一个特定对象的所有可能状态及其引起状态转移的事件。大多数面向对象技术都用状态图表示单个对象在其生命周期中的行为。一个状态图包括一系列的状态以及状态之间的转移。,〔1〕 组成,〔2〕 实例,实例1 对象的状态图,,图中包含

24、以下状态：,,初始状态,Available状态,Locked状态,Sold状态,,状态间的转移：,初始状态Available状态,票被预订(lock)：AvailableLocked,预定后付款(buy)：LockedSold,预定解除(unlock)：LockedAvailable,预定过期(time out)：LockedAvailable,直接购置(assigned to)：AvailableSold,换其它票(exchang) ，该票重有效：SoldAvailable,实例,2,网上银行登陆系统,登陆要求提交个人社会保险号,(SSN),和密码,(PIN),经验证有效后登陆

25、成功。,,登陆过程包括以下状态,:,,初态,(Initial state),获取社会保险号状态,(Getting SSN),获取密码状态,(Getting PIN),验证状态,(Validating),拒绝状态,(Rejecting),终态,(Final state),状态转移过程如下：,,有两个不同的终态,,,,出发状态,动作,到达状态,Initial state,移动鼠标到,SSN,Getting SSN,Getting SSN,键入非,tab,键，显示键入内容,Getting SSN,,键入,tab,键，或移动鼠标到,BIN,Getting PIN,,提交,Validating,Gett

26、ing PIN,键入非,shift-tab,键，显示,“,*,”,Getting PIN,,键入,shift-tab,键，或移动鼠标到,SSN,Getting SSN,,提交,Validating,Validating,验证提交信息有效，状态转移,Final state,,验证提交信息无效，显示错误信息,Rejecting,Rejecting,退出,Final state,,重试，清除无效的,SSN,，,PIN,Getting SSN,4,协作图,,协作图主要描述协作对象间的交互和链接，显示对象、对象间的链接以及对象间如何发送消息。,协作图可以表示类操作的实现。,(1),协作图中的事物及解释,

27、,标签,,,,事物名称,解释,图,参与者,发出主动操作的对象，负责发送初始消息，启动一个操作。,,对象,对象是类的实例，负责发送和接收消息，与顺序图中的符号相同，冒号前为对象名，冒号后为类名。,,消息流,(,由箭头和标签组成,),箭头指示消息的流向，从消息的发出者指向接收者。标签对消息作说明，其中，顺序号指出消息的发生顺序，并且指明了消息的嵌套关系；冒号后面是消息的名字。,,(2),协作图与顺序图的区别和联系,,协作图和顺序图都表示出了对象间的交互作用，但是它们侧重点不同。,顺序图清楚地表示了交互作用中的时间顺序,(,强调时间,),，但没有明确表示对象间的关系。,协作图清楚地表示了对象间的关系

28、,(,强调空间,),，但时间顺序必须从顺序号获得。,协作图和顺序图可以相互转化。,(3),实例,实例,1,打印操作的协作图,actor,发送,Print,消息给,Computer,，,Computer,发送,Print,消息给,PrintServer,，如果打印机空闲，,PrintServer,发送,Print,消息给,printer,。,实例,2,乘坐电梯的协作图,参与者需要乘坐电梯，他从系统外部按下按钮，让电梯到达他想去的楼层。此时，电梯系统的操作被启动，电梯控制对象以循环的方式检查所有的电梯，从中选择一个工作队列长度最短的。然后，它创立一个作业命令，并将该命令放入对应电梯的工作队列，接着

29、激活队列。电梯对象并发运行，从它的队列中选择一个作业并执行。电梯是一个活动对象，它与它的控制线程并发执行。,4.3 UML,核心模型,一、用例模型,用例模型使用用例描述了系统的功能需求，模型化表示了系统的功能和系统的环境。用例模型为客户和开发者提供了一种契约。当客户同意了用例模型，客户希望得到的系统功能也就确定了。在软件开发过程中，用例模型可以作为一种方式用来与系统的客户进行交流。,,用例模型的作用有：,〔1〕 在系统开发的早期就可以明确最后提交的产品功能和特性；,〔2〕 确保双方都对需求有了准确的理解标识〔系统的用户群和系统的功能〕；,〔3〕 确定对系统与用户群之间接口的需求验证〔是否客户所

30、有的需求都被捕获〕；,〔4〕 确保开发团队已完全理解了客户的需求。,用例模型是使用用例的方法来描述系统功能需求的过程。它主要包括两局部内容：用例图和用例描述。用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。,二、业务用例模型和系统用例模型,建立业务用例模型原因：,,因为业务用例模型的目的是为现存的或客户预想中的真实业务建立模型，是为了理解客户的业务，并与客户达成业务理解上的共识而建立的模型。,业务用例模型要准确而完备地描述客户的现存或预想业务，而系统用例模型那么可能只是业务的片段或者局部。,,业务用例模型描述的是业务范围，与系统用例模型讲述的系统范围是不同的。,