用例模型——绘制系统顺序框图(SSD)

合集下载

深入理解用例建模

UML用例建模解析刘伟UML（统一建模语言）是当前软件开发中使用最为广泛的建模技术之一，通过使用UML 可以构造软件系统的需求模型（用例模型）、静态模型、动态模型和架构模型。

UML通过图形和文字符号来描述一个系统，它是绘制软件蓝图的标准语言。

熟练掌握UML建模技术是一个优秀的软件从业人员所必备的基本技能之一，越来越多的软件企业在招聘中也需要应聘者具备一定的UML知识基础和实践经验。

作为UML的初学者，很多人也在尝试使用UML中的图形来描述一个软件系统，构造一个软件系统的蓝图。

然而，在使用UML的过程中，一部分人并没有深入理解这些图的作用，以及这些图在绘制过程中的一些技巧。

我将陆续通过几篇文章来帮助大家更快更好地学习UML，在软件项目中合理使用UML来提高软件开发效率并规范软件开发流程。

在本文中我将结合库存管理系统来深入浅出地讲述UML建模中的第一个模型——需求模型的构造，即用例建模，包括如何绘制规范的用例图、如何编写简洁而又清晰的用例文档、以及怎样通过用例图和用例文档来构造软件系统的需求模型。

在UML中，需求模型又称为用例模型，它主要用于描述系统的功能性需求，即软件可以实现的功能，如登录、注册、入库、出库、查看库存报表、增加员工信息等。

常规的用例建模一般包括两个组成部分：绘制用例图和编写用例文档。

1. 绘制用例图用例图是UML中比较简单的一种图形，它包含两个主要组成元素，分别是执行者(Actor)和用例(Use Case)。

执行者又称为参与者或角色，用例又称为用况或案例。

在用例图中，执行者用一个“小人”符号表示，用例用一个“椭圆”符号表示，因此用例图又有一个名字为“小人椭圆图”。

最简单的用例图如下：入库仓库管理员在该用例图中，“仓库管理员”表示执行者，“入库”表示一个用例，即系统的一个功能。

执行者是指直接和系统交互的一类事物，执行者主要有如下三类：(1) 直接使用系统的人，如使用一个库存管理系统的仓库管理员、仓储部经理等用户，仓库管理员可以通过系统进行入库和出库操作，仓储部经理可以通过系统查看各种报表，如库存报表、财务报表等；(2) 与该系统相关的其他系统，如在库存管理系统中如果涉及到付款操作，需要使用另一个软件——支付系统，此时支付系统就是库存管理的执行者之一；(3) 自动发生的事件，如时间、温度等自动事件，如果库存管理系统要求每晚零点执行一个数据汇总操作，此时时间就成为该操作的执行者。

北邮面向对象课程7第七章细化迭代1：分析

22
领域模型: §7.4 领域模型:添加属性 –在领域模型中不要使用属性来联系概念类
–为数量建模(纯粹的数字没有意义)
23
领域模型: §7.4 领域模型:添加属性
24
用例模型: §7.5 用例模型:用操作契约增加细节
用例模型包含:用例,系统顺序图和操作契约. 操作契约:
–是为系统操作而定义的; –系统操作是作为黑箱的系统在其公共接口中提供的,用于处理系统事件. –系统操作可以通过系统事件来识别. –系统的公共接口:贯穿所有用例的全体系统操作. –定义操作执行的结果(对象状态的改变), 而非过程.
Drawer — Register Wing — Airplane SalesLineItem — Sale FlightLeg—FlightRoute Register — Store, Item — Shelf Passenger — Airplane ItemDescription — Catalog Flight— FlightSchedule ItemDescription — Item FlightDescription — Flight SalesLineItem — Sale Maintenance Job — Maintenance Log Sale — Register Reservation — FlightManifest Cashier — Store Pilot — Airline
27
用例模型: §7.5 用例模型:用操作契约增加细节后置条件
–描述领域模型中对象状态的变化,包括:
实例的创建和删除; 属性的修改; 关联的形成和断开.
– –后置条件是声明性的,而且是面向状态变化而不是面向行为的.正是基于此,后置条件能够在不描述系统操作如何实现的前提下描述系统操作引起系统状态的变化,给出了分析的细节.因此,分析阶段可以集中精力于系统发生了什么而非是如何发生的. –在需求工作时,要为系统操作产生一个完整,详细的后置条件集是不可能甚至是不需要的.(初始契约不完整).

如何绘制用例图

需求中如何画用例图UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。

用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。

从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。

但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。

基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。

基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

包含关系对典型的应用就是复用，也就是定义中说的情景。

但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。

这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。

OOAD总结

第一章1、什么是分析与设计？1、分析强调对问题和需求的调查研究2、设计强调的是满足需求的概念上的解决方案2、什么是面向对象分析与设计？1、在面向对象分析过程中，强调的是在问题领域内发现和描述对象（或概念）2、在面对对象设计过程中，强调的是定义软件对象以及它们如何协作以实现需求。

3、简单示例：1、定义用例（use case）需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例。

2、定义领域模型（domain model）面向对象分析的结果可以表示为领域模型，在领域模型中展示重要的领域概念或对象。

需要注意的是，领域模型并不是对软件对象的描述，它使真实世界领域中的概念和想象可视化。

（也被称为概念领域模型—conceptual object model）3、定义交互图关注的是软件对象的定义—它们的职责和协作。

顺序图（sequence diagram）是描述协作的常见方法。

它展示对象之间的信息流，和由消息引起的方法调用。

4、定义设计类图除了在交互图中显示对象协作的动态视图外，还可以用设计类图（design class diagram）来有效的表示类定义的静态视图。

这样可以描述类的属性和方法。

与领域模型表示的是真实世界的类，设计类图表示的是软件类要注意的是，尽管设计类图不同于领域模型，但是其中的某些类名和内容还是相似的。

第二章1、什么是UML？统一建模语言（UML）是描述、构造和文档化系统制品的可视化语言。

UML表示法的基础是UML元模型，它描述建模元素的语义，UML元模型对模型驱动架构（Model Driven Architecture, MDA）CASE工具供应商具有影响。

开发者并不需要对其进行学习。

2、三种UML应用方式1、UML作为草图—非正式的、不完整的图，借助可视化语言的功能，用于探讨问题或解决方案空间的负责部分。

2、UML作为蓝图—相对详细的设计图。

用于：①逆向工程；②代码生成。

9-绘制用例顺序图

:System
description, total
endSale return value(s) associated with the previous message an abstraction that ignores presentation and medium the return line is optional if nothing is returned
20
POS部分领域模型
Records-sale-of Product Description Contains 1 1 0..1 Sales LineItem 1 Recordsaccountsfor 1 Used-by Describes 1..* Ledger Product Catalog
15
操作契约的编写
操作契约更为详细和精确的描述领域内对象
的变化针对一个系统操作，分析领域模型内的对象变化（实为对待这一系统操作的内部实现过程）
操作: 交叉引用: 前置条件: 后置条件: enterItme(itemID,quantity) 处理销售正在进行的销售创建saleLineItem的实例sli sli与当前sale关联 sli.quantitiy赋值为quantity 基于itemId的匹配,将sli关联到ProductDesc
:System
系统顺序图中出现有数据元素应放入词汇表中，在词汇表中详细描述为复杂的场景建立系统顺序图

scan(itemID, quantity) worse name
9
Monopoly模拟游戏场景
10
ATM查询用例
ATM
查询-基本事件流 1. 用户插入银行卡 2. 用户身份验证 3. 系统通过用户身份验证，并显示主菜单 4. 用户选择查询 4. 系统显示帐户余额 5. 用户请求打印回执， 6. 系统打印回执，返回主菜单 7. 用户退出系统，取回银行卡

UML建模风格之顺序图

UML建模风格之顺序图和合作图、活动图一样，UML顺序图( Rumbaugh、Jacobson、和booch, 1999)是一种动态建模方法。

UML顺序图一般用于：1.确认和丰富一个使用情境的逻辑。

一个使用情境就是系统潜在的使用方式的描述，也就是它的名称所要描述的。

一个使用情境的逻辑可能是一个用例的一部分，或是一条备选线路；一个贯穿单个用例的完整流程，例如动作基本过程的逻辑描述，或是动作的基本过程的一部分再加上一个或多个的备用情境的逻辑描述。

或是包含在几个用例中的流程，例如一个学生注册入学之后，立即就要在三个班级注册。

2.研究你的设计，因为它们为你提供了一种方式，你可以使用这种方式来可视化的调用类定义的操作。

3.检测面向对象的设计中的瓶颈。

通过观察什么消息被发送给一个对象，以及通过概略的观察运行被调用的方法需要花费多长时间，你很快就能了解那里的设计需要变化，以达到在系统内部平衡负荷的目的。

实际上某些CASE工具甚至能够让你模拟软件这些特征。

4.使你能够感觉到你的应用程序的那个类将会变得复杂的，这是个信号，意味着你需要为那些类画状态图了。

指南∶通用准则尽力保持消息的顺序从左到右排列将分类器分层用和你的用例图一致的名称命名角色用和你的类图一致的名称命名类一个角色的名称可以和类的名称相同包含一个逻辑的叙述性描述在图的最左边放置初始的角色在图的最左边放置人和组织角色在图的最右边放置系统角色只在合适的时候才建模对象的Destruction分类器的原则当你在消息上引用对象时要命名他们当存在部分相同的类型时需要命名对象一致地应用文本版型少量地应用可视化的版型集中在关键的交互消息的原则把消息名放在箭头旁边直接创建对象为软件消息使用操作符号为涉及人和组织角色的消息使用叙述性文字推荐使用参数名称，而不是参数类型为参数占位符注明类型类的消息实现为静态操作为用例调用使用<<include>>版型返回值的原则当返回值非常明显时就不要对返回值建模只有当你需要在别处引用返回值时才对返回值建模在箭头旁边调整返回值返回值建模为方法调用的一部分为返回值占位符注明类型明确的为简单值标明实际值一、通用准则1.尽力保持消息的顺序是从左到右排列的一个顺序图的消息流开始于左上方，消息乙的位置比消息甲低，这意味着消息乙的顺序比消息乙要迟。

用例框图(UseCase Diagram)简介

用例框圖(UseCase Diagram)簡介用例框圖顯示系統中的用例與角色及其相互關係。

用例是系統提供的高級功能塊，角色是與所建系統交互的物件。

下圖是個用例框圖的例子：用例(UseCase)用例是系統提供的功能塊。

換句話說，用例演示了人們如何使用系統。

下圖表示一個"登錄"的用例：用例之間一般有兩種關係：擴展關係，包含關係。

屬性∙General：常規屬性o a bstract：抽象。

是否是抽象類o c lassifier behavior：類元行為。

指定定義類行為的活動、交互、狀態機。

這些行為詳細定義了類的行為特徵。

o e xtends：繼承。

類的父類。

直接繼承的父類。

o f inal：是否可繼承。

final類不可被繼承。

o f ull name：全名。

包含路徑的全名，如java.util.zip。

o g uid：元素唯一ID。

o m etaclass：元類。

模型元素的元類。

o n ame：名字。

o p rovided interface：提供介面。

即實現的介面。

o r equired interface：需求介面。

即類使用到(Usage依賴)的介面。

o s tereotype：構造型。

可選擇，也可自行輸入。

o s ubject：主題。

選擇用例表達主題。

o v isiblity：可見性。

∙Custom：自定義o t agged value：標記值。

如"query=true"∙Description：描述o d escription：元素的描述資訊∙View：顯示屬性o3D look：是否顯示陰影o a uto resize：是否自動改變元素尺寸。

o b ackground：背景色o f ont：字體o f oreground：前景色o v iew as class：顯示類樣式。

模型導航區快顯功能表∙new：新建：以當前包為命名空間，創建以下元素：o E xtension Point：擴展點∙new diagram：新建框圖。

2.设计模式常用的UML图分析（用例图、类图与时序图）

2.设计模式常⽤的UML图分析（⽤例图、类图与时序图）1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。

2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况，⽤于建⽴需求模型。

⽤例特征保证⽤例能够正确捕捉功能性需求，判断⽤例是否准确的依据。

1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中，参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务，于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中，⼀个实际⽤户可能对应系统的多个参与者。

不同⾓⾊也可以只对应⼀个参与者，从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。

系统的功能由系统单元所提供，并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。

系统单元⽤椭圆表⽰，椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。

箭头指向：指向消息接收⽅：⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。

⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。

⽗⽤例通常是抽象。

箭头指向：指向⽗⽤例2-类图描述系统中的类，以及各个类之间的关系的静态试图。

表⽰类、接⼝以及它们之间的协作关系，⽤于程序设计阶段。

注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝，则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图，类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性，则每⼀个属性都必须有⼀个名字，另外还可以有其它的描述信息，如可见性、数据类型、缺省值等2. 操作:如果有操作，则每⼀个操作也都有⼀个名字，其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。

程序框图顺序结构条件结构

结束
开始输入a1,a2 将a1与a2的和记作b
（1）如图1所示的是一个算法的流程图,已知a1=3,输出的b=7,则a2的值是( A )
A.11 B.17 C.0.5 D.12
x＝2
将 b 记作b 2
输出b
y1＝x2-1 y＝y12-1
（2）.如图2所示的流程图最终输出的结果是 ____8____.
输出“及格”
输出“不及格”
结束
1. 用自然语言表示优点是使用日常用语, 通俗易懂缺点是文字冗长, 容易出现歧义
2. 用程序框图表示: 用图框表示各种操作优点是直观形象, 易于理解
谢谢
输入a,b,c
p 234 2
解：求面积的算法:
第一步:输入三角形三边长a,b,c
Sp(p2)p (3)p (4)
第一步:计算 p abc
2
第二步:计算 Sp (pa )p (b )p (c)
输出S
第三步:输出三角形的面积S
结束
练习1 设计一算法：输入圆的半径,输出圆的面积，并画出流程图
算法分析：
第一步：输入圆的半径
第二步：利用公式“圆的面积=圆周率×（半径的平方）” 计算圆的面积；第三步：输出圆的面积。
开始定义Pi=3.14 输入半径R 计算S=Pi*R*R
输出面积S
结束
例2：已知两个单元分别放置了变量x和y值，试交换两个变量。
开始
解：为了达到交换的目的，需要一个单元存放中间变量p. 其算法是：
Y
r=0 N
Y
输出”n不是质数”
结束
输出”n是质数”
（1）终端框是任何流程图不可缺少的，表明算法的开始或结束。
（2）输入输出框可用在算法中任何需要输入、输出的位置，需要输入的字母、符号、数据都填在框内。

用例模型及系统顺序图

多次迭代，用例分优先级，早期的需求会议集中于最重要的用例
早期的需求会议集中于最重要的用例后面的需求会议适应和精化核心需求，逐步稳定发现需求和建造部分软件系统相辅相成
各阶段的对于POS system ，20 user goal level use cases中，最复杂和具有风险的15个或更多用fully dressed format写出或重写
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取：目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
❖ Rose演示
绘图
UML用例图
❖ 用例工作主要是写文本文档，图是次要的 ❖ 初学者常先画图，世界级用例专家关注文本， ❖ 建议：在参与者目标列表同时画简单的用例
图，显示系统边界、系统和参与者的行为：
识别其他需求
识别其他需求
❖ UC对需求分析来说并不充分，还需要识别其他种类的需求
补充规约Supplementary Specification
❖ 用例、词汇表中不易捕获的需求、信息和约束
Functional， Usability， Reliability，Performance，Supportability
UML用例图-绘图的建议
❖ 防止过度图形化 ❖ 用例的重点在于书写文本，而不是图和用例
关系，不要花很多小时甚至几天讨论用例图和用例关系
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取：目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
用例驱动的开发过程
❖ 需求主要记录在用例中 ❖ 用例是迭代规划重要组成部分，选择不同的
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取：目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求

系统顺序图

含的交互可视化 2、这个是本书提出的制品，也是非常有价值
的，虽然RUP中没有提到。
3、SSD的制品输入与输出关系讨论？
操作契约
领域模型
系统顺序图
迭代1需求
其他需求
与用例的关系
什么是系统顺序图
用例描述外部参与者是如何与我们所希望创建的
系统进行交互的。
在交互中，参与者发起系统事件（system event）,通常需要某些系统操作（system
operation）对这些事件进行处理。
系统顺序图表示：对于用例的一个特定场景，
external actor to system
a UML loop interaction frame, with a boolean guard expression
Fig. 10.2处理销售场景的 SSD
system as black box
the name could be "NextGenPOS" but "System" keeps it simple
这一阶段限定系统的应用为黑盒而在设计阶段借助领域模型进行交互软件对象的设计讲解流程基于对领域建模的讨论在ssd中确定系统操作接下来执行这些操作并使用前置条件和后置条件等操作契约表示法来描述这些操作对领域对象所产生的影响其他需求迭代1需求领域模型系统顺序图操作契约什么是系统顺序图与用例的关系描述外部参与者是如何与我们所希望创建的系统进行交互的
示例：NextGen SSD
对于一系列特定事件，SSD展示了直接与系统交互的外部参与者、系统（作为黑盒）以及由参与者发起的系统事件，在图中，时间顺序是自上而下的，并且事件顺序遵循其在用例场景中的顺序。
注意：UML没有专门定义系统顺序图，而只是定义了顺序图，这里系统顺序图强调将系统视为一个黑盒事务，描述系统行为。

教你3步画好时序图,轻松掌握产品经理都在学的流程分析利器

产品经理简称PM，是指在公司中针对某一项或是某一类的产品进行规划和管理的人员，主要负责产品的研发、制造、营销、渠道等工作。

产品经理是很难定义的一个角色，如果非要一句话定义，那么产品经理是为终端用户服务，负责产品整个生命周期的人。

产品经理需要考虑目标用户特征、竞争产品、产品是否符合公司的业务模式等等诸多因素。

近年来互联网产品经理火热，一起看下为大家精选的互联网产品经理学习文章。

上次介绍了活动图，这次UML 中，另一种流程分析利器——时序图。

以前每次要分析流程，我都会用活动图。

直到有一次，我面对一个业务流程，画活动图，画来画去，总觉得哪里不对，但又表达不出来，感觉如鲠在喉。

后来，我想起时序图，用时序图把流程梳理了一遍，豁然开朗。

原来，用不同的视图去描述同一个流程，能让我们看到自己未曾发现的问题。

就像看足球比赛，在多个不同位置的摄像镜头下，能看到球员更全面的表现。

此后，我用时序图甚至比活动图还多。

那么，它有啥特别之处，居然能替代活动图来分析流程？我们一起来看看。

01 解读时序图时序图，也叫序列图、顺序图，是UML 中常用的动态视图，用于描述多个对象参与实现业务目标时，彼此之间按时间顺序进行交互的过程。

时序图，用来表达对象或角色之间交互的信息传递和时间顺序，特别方便。

每次梳理流程，跟开发沟通，我都会借助它来描述。

绘制时序图，将一个个对象和其交互动作列出来，可以直观反映出，每个对象对其他对象、或其自身做的交互动作，让我们看到业务内部的运作、系统之间的互动，从而搞清楚业务规则、系统逻辑。

在《火球：UML 大战需求分析》一书中，作者总结特别好：“任何复杂的交互，都可以分解为自己与自己、自己与别人、别人与别人的多个简单交互”。

时序图正体现了这种逻辑，所以，它表达交互逻辑时，非常清晰简单。

客户用ATM 取款的时序图作为产品经理，如果我们能掌握这一利器，用来分析业务、定义需求，与开发沟通，定能大大提高效率。

时序图常见的应用场景，是在支付领域。

顺序图的建模步骤

顺序图的建模步骤1．创建和删除顺序图1.1 创建顺序图新建一个顺序图的方式有两种：1.1.1 在逻辑视图中增加顺序图1）一般情况下，顺序图属于系统的逻辑模型，因此可以使用“Logical View”的右键菜单——〉“New”——〉“Sequence Diagram”，如下图所示：然后输入顺序图的名称，如下图所示：接着双击新增的顺序图名称，开始输入顺序图，如下图所示：1.1.2 在用例视图中增加顺序图顺序图主要是用于对用例的描述，在此种目的下新增顺序图的方式也是有两种：2.1）直接在“Use Case View”下的相应用例上通过右键菜单——〉“New”——〉“Sequence Diagram”菜单项新建一个顺序图，如下图所示：输入顺序图的名称，如下图所示：输入完顺序图的名称后，双击此顺序图的名称开始输入顺序图的内容。

2.2）在用例图中使用用例的属性窗口来新增顺序图。

如下图所示，在用例“浏览课件”的“Specification”属性窗口中的“Diagrams”项目下，通过右键菜单——〉“Insert Sequence Diagram”，输入顺序图的名称，如下图所示：双击此顺序图名称，进入顺序图的编辑界面。

1.2 删除顺序图不管是在逻辑视图（Logical View）还是在用例视图（Use Case View），删除顺序图的方式都是一样的。

都是选中需要删除的顺序图，右键菜单——〉“Delete”，即可直接删除，如下图所示。

注意，在Rational Rose2003环境下，所有的删除操作都是没有提示的。

1.3 修改顺序图的名称不管是在逻辑视图（Logical View）还是在用例视图（Use Case View），修改顺序图名称的方式都是一样的。

都是选中需要修改名称的顺序图，右键菜单——〉“Rename”，如下图所示：2．增加和删除对象2.1 增加对象在顺序图中，增加对象的方式主要有两种：2.1.1 使用原有的模型元素作为顺序图的对象使用拖放的方式把原有的模型元素作为顺序图的对象，如下图所示：注意：可以被拖放的模型元素有参与者（Actor）和类（Class）这两种模型元素。

UML5分析阶段用例建模用例图顺序图.ppt

（1）用例建模
▪ 绘制用例图 ▪ 对每一个用例书写用例模版。 ▪ 对每一个用例绘制顺序图以给出其基本事件
流的图形表达。
用例图概述
▪ 用例图用于描述外部用户或外部系统（参与者）使用系统完成业务功能。
▪ 属于用例视图，也称为外部视图、功能视图、用户视图。
▪ 两个概念：参与者与用例。
自动饮料售货机系统用例图
▪ “通信”关系：使用实心的关联线或连接两个用例。表示前一个用例执行完毕接着启动执行后一个用例。
▪ 是用例间的默认关系。因此一般省略 <<communicate>>构造型。
用例间的包含关系
▪ “包含”关系：使用虚的依赖线加上<<include>>
构造型，形如
的形式连接两个用例。表示前一
个用例的执行需要借助调用后一个子用例的功能。后一
失败两大类。 • 8. 特殊需求说明：备注其它事项。
事件流描述
▪ 用例模版中最主要的部分是该用例的事件流描述。它描述参与者在系统边界处使用系统执行该用例的交互细节，并不涉及该用例内部的处理细节。
▪ 基本上是“系统xxx”,”用户xxx”的逐条交互形式，但要注意备选事件流。
用例建模
▪ （1）首先给出一个系统的业务描述文字。 ▪ （2）然后给出用例图描述这个系统的业务，方便
启发式提问识别参与者
• 谁对系统的某一需求（功能）感兴趣？ • 谁对系统运行产生的结果感兴趣 • 谁改变系统的数据 • 谁从系统获取信息 • 谁需要系统的支持以完成日常工作任务 • 谁负责维护、管理并保持系统正常运行 • 系统需要应付那些硬件设备 • 系统需要和那些外部系统交互 • 时间、气温等内部外部条件 • ……

用例图一般建模流程

用例图一般建模流程下载温馨提示:该文档是我店铺精心编制而成，希望大家下载以后，能够帮助大家解决实际的问题。

文档下载后可定制随意修改，请根据实际需要进行相应的调整和使用，谢谢!并且，本店铺为大家提供各种各样类型的实用资料，如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等，如想了解不同资料格式和写法，敬请关注!Download tips: This document is carefully compiled by theeditor. I hope that after you download them,they can help yousolve practical problems. The document can be customized andmodified after downloading,please adjust and use it according toactual needs, thank you!In addition, our shop provides you with various types ofpractical materials,such as educational essays, diaryappreciation,sentence excerpts,ancient poems,classic articles,topic composition,work summary,word parsing,copy excerpts,other materials and so on,want to know different data formats andwriting methods,please pay attention!用例图是一种用于描述系统功能和用户与系统之间交互的图形化工具。

以下是用例图的一般建模流程：1. 确定系统边界和范围：明确系统的边界和范围，包括系统的主要功能和与外部系统的交互。

用例模型——绘制系统顺序框图(SSD)

arameters it is an abstraction representing the system event of entering the payment data by some mechanism
total with taxes
makePayment(amount)
:System
loop,until all book are recorded
endRental() Lental
用例名：记录预约餐馆预约系统参与者：接待员前置条件：接待员已获得系统授权后置条件：系统记录预约主要成功场景： 1. 接待员输入要预约的日期 2. 系统显示该日的预约 3. 有合适的餐桌，接待员输入顾客的姓名和电话号码、预约时间、用餐人数和餐桌号。 4. 系统记录并显示预约
ta xL in e Ite m s = g e tT a xe s ( sa le )
用例简述顾客在购物网站上输入注册信息，成为网站会员。
基本事件流 1 顾客在会员注册画面，输入用户编号、密码、用户姓名、电子邮件地址和联系电话等信息，提交注册请求。 2 系统对顾客的信息进行检查，并保存顾客的信息。 4 系统提示顾客注册成功。
enteritemitemidquantityendsalemakepaymentamountdescriptiontotaltotaltaxeschangeduereceiptmakenewsalemoreitemsloopprocesssalescenario通过系统事件获得所有系统操作system系统事件及其相关的操作应该表达意图而不是物理输入介质或窗口界面以最高层次或最终极的目标命名操作ssd从uc文本中识别每个参与者生成的系统外部事件在图中表示出来创建系统顺序图案例

用例模型及系统顺序图

此外，细化结束时已有具有一定质量的可执行代码
各阶段的需求分析
❖ Construction
20个迭代，每个2周，以完成系统。细化阶段风险和核心不稳定问题都解决了以后开
始用例和需求仍可作微量变化
例子：初始阶段用例模型
outline
❖ 用例的概念 ❖ 用例书写格式 ❖ 用例的提取：目标-->用例 ❖ 绘图 ❖ 用例驱动开发过程 ❖ 其他需求
❖ 最细化，包括所有步骤和变化。可有前置条件、后置条件（成功保证）
❖ 可获得对目标、任务和需求的深入理解 ❖ 在早期需求讨论会上与system analyst, subject
matter experts, and developers协同创建 ❖ 有各种模板 ❖ Process Sale 实例分析
用例场景部分定义了迭代工作 ❖ 设计阶段主要设计对象协作和子系统来实现
用例 ❖ 用例影响用户手册的组织
❖ 10%的需求详细化后就开始建造系统的核心
❖ 需求分析交错进行，细化阶段第一次迭代结束时，第二次需求会议，完成30%详细用例，并接受反馈
各阶段的需求分析
❖ Inception: ❖ 两天需求分析会议和简单的用例分析
❖ Constraints也是需求，强调其限制性
Must use Oracle (we have a licensing arrangement with them). Must run on Linux (it will lower cost).
词汇表Glossary 前景（构想）Vision
❖ 从受益人(关系人，风险承担者Stakeholder)的角度看要开发的系统：为什么提出该项目、问题是什么、受益人是谁、他们需要什么

软件工程生命周期各阶段中的图示例

软件工程中的图软件工程导论中一般把软件的开发分为八个阶段：１.问题定义２.可行性研究３. 需求分析４. 总体设计（概要设计）５. 详细设计６. 编码和单元测试７. 综合测试８. 软件维护下面我们就说说各个阶段中与图的难解难分。

１. 问题定义问题定义阶段主要是根据用户的需求来定义用户需要解决的问题，用户要实现哪些功能。

２. 可行性研究可行性研究阶段就是看是否有一种使其在最小的代价，尽可能短的时间内，利益最大化的情况下解决问题的方案。

这个阶段的分析主要涉及以下几个图形工具。

2.1系统流程图系统流程图是描述系统物理模型的一种传统工具。

它是表达数据在系统各部件之间流动的情况，而不是对数据加工处理的控制过程，它是物理数据流图而不是程序流程图。

系统流程图形象的呈现了软件的功能，即使不懂软件的人也可以轻松的看懂，可以说它是软件设计师与用户之间沟通、交流的有效工具。

2.2数据流图数据流图是从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。

如果说系统流程图能让用户更好的明白系统的功能，那么数据流图则让用户更加明白系统的工作原理。

数据流图的基本符号：数据流图的使用例子：2.3数据字典数据字典就是数据的信息的集合，也可以说就是对上面提到的数据流图中的所有元素的定义的集合。

数据字典的主要作用就是在软件的分析与设计阶段方便我们查阅不甚了解的数据的描述信息。

３. 需求分析需求分析阶段主要确定系统必须做什么。

比如用户对系统的要求，确定目标系统所有的功能，确定系统运行的硬件和软件环境，系统性能要求，出错处理要求，接口需求，验证软件需求等等。

3.1 E-R图E-r 图的主要作用就是把用户的数据要求用可视化的图形呈现出来。

3.2状态转换图状态转换图说白了就是系统的行为建模，就是通过描述系统的状态以及引起状态变化的事件来表示系统的行为，将系统运行时详细的状态变化呈现给用户。