数据库用例图
UML用例和用例图
h
18
主要内容
基本概念：Use case、Actor、
Scenario Use case间的关系 Use Case 分析技术 案例讲解
h
19
关系
• 参与者与用例之间
– 关联关系
• 用例与用例之间
– 包含关系 (include) – 扩展关系 (extend) – 泛化关系 (generalization)
• 主事件流： • 1、系统显示ID和密码窗口； • 2、顾客键入ID和密码，然后按OK键； • 3、系统验证顾客ID和密码，并显示个人信息窗口； • 4、顾客键入姓名、街道地址、城市、邮政编码、电话号码，然
后按OK键； • 5、系统验证用户是否为老顾客； • 6、系统显示可以卖的商品列表； • 7、顾客在准备购买的商品图片上单击，并在图片旁边输入要购
• 用例结束后的系统状态
• 其他需要描述的内容
用例描述原则：尽可能写的“充分”，而不是追求写的形 式化、完整或漂亮。
h
32
h
33
书写用例文档
——路径交互步骤的描述
只书写“可观测”的 使用主动语句 句子必须以执行者或系统作为主语 每一句都要朝目标迈进 分支和循环 不要涉及界面细节
h
34
书写用例文档
买的数量。选购商品完毕后按Done按钮； • 8、系统通过库存系统验证要购买的商品是否有足够库存； • …….（后续描述省略）
问题：对用户界面的描述过于详细，对于需求文档来说， 详细的用户描述对获取需求并无帮助。
h
45
改进后的描述
• Use Case：Buy Something • 参与者：Customer • 主事件流： • 1、顾客使用ID和密码进入系统； • 2、系统验证顾客身份； • 3、顾客提供姓名、地址、电话号码； • 4、系统验证顾客是否为老顾客； • 5、顾客选择要购买的商品和数量； • 6、系统通过库存系统验证要购买的商品是否有足
第03章 用例和用例图
5
用例的特点 ① 用例用于描述系统的功能，这个功能是外 部使用者看到的系统功能，不反映功能的实现 方式。
储蓄系统
开户 存款
√
√ √ √
取款
转帐
6
用例的特点
② 用例描述用户提出的一些可见需求，对应 一个具体的用户目标。
储蓄系统 √ √ √ 开户 存款 取款 转帐
√
×
数据上传
7
用例的特点 ③ 用例反映系统与用户的一次交互过程，应 该具有交互的信息的传递。
泛化关系代表一般与特殊的关系, 与继承类似.
在泛化关系中, 子用例继承了父用例的行为和含义, 子用例也可以增加新的行为和含义或覆盖父用例中 的行为和含义.
20
3.4.2 泛化关系
21
3.4.3 包含关系
包含关系是指一个用例(基本用例)的行为包含了另一 个用例(包含用例)的行为.
包含关系是依赖关系的版型, 但其含义更多.
3.6 用例的描述
用例阐述：写用例规约
用例规约：更进一步的精度
用例文档的核心，作为用例文档的总图 进一步的精度：有层次的文档 文档中每一句话都有其价值
用例图是骨架，而用例规约则是其内在的血肉
43
3.6 用例的描述
谁来写用例文档 ?
最完美：业务人员接受训练，写出优美的 用例文档 最现实：业务人员提供素材，开发人员写 用例文档 最糟糕：业务人员不管，完全由开发人员 杜撰
3
3.7 寻找用例的方法
3.8 用例的常见问题
15
3.3 脚本
脚本(scenario)在UML中指贯穿用例的一条单一路径, 用来显示用例中的某种特殊情况. 其它译名: 情景、场景、情节、剧本.
E-R图和用例图
E-R图和用例图图1E-R图目录E-R图概念E-R方法概念E-R模型历史构成E-R图的基本要素作E-R图的步骤作E-R图举例设计分E-R图的步骤展开编辑本段E-R图概念E-RE-R图也称实体-联系图(Entity Relationship Diagram)，提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。
编辑本段E-R方法概念E-R方法是“实体-联系方法”（Entity-Relationship Approach）的简称。
它是描述现实世界概念结构模型的有效方法。
是表示概念模型的一种方式，用矩形表示实体型，矩形框内写明实体名；用椭圆表示实体的属性，并用无向边将其与相应的实体型连接起来；用菱形表示实体型之间的联系，在菱形框内写明联系名，并用无向边分别于有关实体型连接起来，同时在无向边旁标上联系的类型（1:1,1:n或m:n）。
编辑本段E-R模型历史ER模型最早由Peter Chen于1976年提出，它在数据库设计领域得到了广泛的认同，但很少用作实际数据库管理系统的数据模型。
即使对SXL-92数据库来说，设计好的数据库也是具有挑战性的。
它们可以在许多关于数据库设计的文献中找到，比如Toby Teorsey 的著作（1994 ）。
大部分数据库设计产品使用实体-联系模型（ER模型）帮助用户进行数据库设计。
ER数据库设计工具提供了一个“方框与箭头”的绘图工具，帮助用户建立ER 图来描绘数据。
实体联系模型，实体关系模型或实体联系模式图(ERD)是由美籍华裔计算机科学家陈品山(Peter Chen)发明，是概念数据模型的高层描述所使用的数据模型或模式图，它为表述这种实体联系模式图形式的数据模型提供了图形符号。
这种数据模型典型的用在信息系统设计的第一阶段；比如它们在需求分析阶段用来描述信息需求和/或要存储在数据库中的信息的类型。
但是数据建模技术可以用来描述特定论域(就是感兴趣的区域)的任何本体(就是对使用的术语和它们的联系的概述和分类)。
UML05用例图模板
⑤ 绘制用例图。
34
5.5 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化，包含，扩展)。 ⑤ 绘制用例图。
●
⑥ 编制用例描述。
35
5.5 发现用例
发现用例的一般方法：
出纳员
吃饭
系统需要处理的，由系统生成
44
要点：业务语言而非技术语言
• 用户词汇，而不是技术词汇
– 如：发票，商品，洗衣机 – 而不是：记录，字段，COM，C++等
45
要点：用户观点而非系统观点
订票 旅客 查看今日航班
处理订票
旅客
显示今日航班
用户观点
系统观点
46
思考题：识别用例
• Email客户端（如：outlook express），A在 北京发邮件给上海的B，系统提醒B你有 “新邮件”，B收邮件。
用例描述
用例描述一般包括的内容：
用例的目标 用例是怎么启动的 参与者与用例之间的消息如何传送 用例中除了成功场景外, 其它场景是什么 用例结束后系统的状态 其它需要描述的内容
56
用例阐述文档
• 场景（scenario）： 是参与者和被讨论 系统之间的一系列特定活动和交互。每个 用例是一组场景的集合，而每个场景又是 一个步骤序列。 • 用例阐述文档针对每个用例，描述各个场 景
38
5.5.2 获取用例
一旦获取了参与者,就可以对每个参与者提出问题以获取用例。 •执行者要求系统提供哪些功能(执行者需要做什么)? •执行者需要读、产生、删除、修改或存储的信息有哪些类型。 •必须提醒执行者的系统事件有哪些? 或者执行者必须提醒系统 的事件有哪些? 怎样把这些事件表示成用例中的功能? •为了完整地描述用例,还需要知道执行者的某些典型功能能否 被系统自动实现? 还有一些不针对具体参与者问题(即针对整个系统的问题): •系统需要何种输入输出? 输入从何处来? 输出到何处? •当前运行系统(也许是一些手工操作而不是计算机系统)的主要 问题?
05 用例视图
Remove Reservation
即可
不管是C、R、U、D，都是为了完成“管理”目标
甚至很多种的基本数据管理都可以用一个用例表示
管理员
管理用户
要点5：用例粒度
灵活处理CRUD
<<extend>>
管理员
管理用户
增加用户
可以把包含复杂交互的路径独立出去形成用例
用例与事件流
用例分析是处于系统的需求分析阶段，这 个阶段应该尽量的避免去考虑系统实现的 细节问题。也就是说，用例描述的是一个 系统做什么，而不是怎么做。
所有业务最终对会成为 CRUD？ CRUD能为Actor提供价 值？ CRUD掩盖业务，锐变成 关系数据库的建模：
增加用户
修改用户
管理员
“系统就是数据的增 删改查” 关心数据的存储和维 护，反而忽略了用户 的目的
查询用户
删除用户
要点5：用例粒度
如果确实是CRUD？
如果CRUD不涉及复杂的交互，一个用例“管理××”
Actor
题外话：小人与圣小猪
参与者虽然用人形图符表示，但参与者不 局限于表示人
如果我开发一个猪圈自动供食供水系统， 猪的前蹄触发一个开关系统就供食或供水。 显然，这里的Actor 是小猪。
Pig
Turn on the switch
题外话：小人与圣小猪
如果在use case 图里用小猪代替原来的小人？
实例—图书馆管理系统中的用例 视图
确定系统涉及的内容
书籍的借阅、读者的统一管理等
确定系统的参与者
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.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。
E-R图和用例图
E-R图和⽤例图E-R图和⽤例图图1E-R 图⽬录E-R 图概念E-R ⽅法概念E-R 模型历史构成E-R 图的基本要素作E-R 图的步骤作E-R 图举例设计分E-R图的步骤展开编辑本段E-R图概念E-RE-R图也称实体-联系图(Entity Relationship Diagram)，提供了表⽰实体类型、属性和联系的⽅法，⽤来描述现实世界的概念模型。
编辑本段E-R⽅法概念E-R⽅法是“实体-联系⽅法”（Entity-Relationship Approach）的简称。
它是描述现实世界概念结构模型的有效⽅法。
是表⽰概念模型的⼀种⽅式，⽤矩形表⽰实体型，矩形框内写明实体名；⽤椭圆表⽰实体的属性，并⽤⽆向边将其与相应的实体型连接起来；⽤菱形表⽰实体型之间的联系，在菱形框内写明联系名，并⽤⽆向边分别于有关实体型连接起来，同时在⽆向边旁标上联系的类型（1:1,1:n或m:n）。
编辑本段E-R模型历史ER模型最早由Peter Chen于1976年提出，它在数据库设计领域得到了⼴泛的认同，但很少⽤作实际数据库管理系统的数据模型。
即使对SXL-92数据库来说，设计好的数据库也是具有挑战性的。
它们可以在许多关于数据库设计的⽂献中找到，⽐如Toby Teorsey 的著作（1994 ）。
⼤部分数据库设计产品使⽤实体-联系模型（ER模型）帮助⽤户进⾏数据库设计。
ER数据库设计⼯具提供了⼀个“⽅框与箭头”的绘图⼯具，帮助⽤户建⽴ER 图来描绘数据。
实体联系模型，实体关系模型或实体联系模式图(ERD)是由美籍华裔计算机科学家陈品⼭(Peter Chen)发明，是概念数据模型的⾼层描述所使⽤的数据模型或模式图，它为表述这种实体联系模式图形式的数据模型提供了图形符号。
这种数据模型典型的⽤在信息系统设计的第⼀阶段；⽐如它们在需求分析阶段⽤来描述信息需求和/或要存储在数据库中的信息的类型。
但是数据建模技术可以⽤来描述特定论域(就是感兴趣的区域)的任何本体(就是对使⽤的术语和它们的联系的概述和分类)。
用例和用例图
技巧 实地观察
访谈
描述
• 直接观察个人工作旳情况，以发觉现存旳实践方式和
问题
• 从个人处搜集特定信息
特定群体 调查
对一组人员进行调查，以便了解工作态度和共同看法
• 问卷调查 搜集详细数据和统计意义上比较主要旳数据
• • 顾客指 导
让最终顾客告诉你，他们是怎样操作系统旳
• 原型制作 模拟一种无法直接测试旳系统
人、外部系统、外部因素等
12
3.2.2 辨认参加者：参加者要点
• 参加者指在系统中所扮演旳角色。即在拟定参加者时，
应主要考虑他旳角色，而不是这个角色旳实例。
• 某些组织中可能有诸多营销人员，但他们均起着同
一种作用，扮演着相同旳角色。
• 一种顾客也能够扮演多…种角色：一种高级营销人员
既能够是贸易经理，也能够是一般旳营销人员。
小一点旳蓝色大理石
5
3.2.1 获取原始需求：如此脆弱
客户/顾客旳要 求/想法/期望
验收
分析和设计
没价值旳 软件需求
补文档
软件产品 编码和测试
软件设计
6
3.2.1 获取原始需求：也需要开发
客户/顾客旳要 求/想法/期望
软件产品
开发
验收
编码和测试
有价值旳 软件需求
分析和设计
软件设计
7
3.2.1 获取原始需求：技巧
第三章 用例和用例图
1
3.1 概述
• 用例图着重从系统外部执行者旳角度来描述系统需要提
供哪些功能，执行者能够是人或外部系统。
2
3.1 概述
用例图旳构成元素
• 图中旳元素涉及：参加者、用例、某些表达关系旳连接
第2章 用例图
16
2.1.4 关系
UML建模与分析
包含include
箭头方向由基本用例指向被包含用例； 两个以上用例有共同功能，可分解到单独用例，形成包含依 赖； 执行基用例时，每次都必须调用被包含用例，被包含用例也 可单独执行；
17
2.1.4 关系
UML建模与分析
包含include
一个用例功能过多需分解成小用例，构成包含依赖；
42
2.5 小结
UML建模与分析
了解用例图的组成 能够绘制用例图 理解如何确定用例、活动者
43
2.6 实例
UML建模与分析
有一个爱书之人，家里各类书籍已过千册，而平时又 时常有朋友外借，因此需要一个个人图书管理系统。 该系统应该能够将书籍的基本信息按计算机类、非计 算机类分别建档，实现按书名、作者、类别、出版社 等关键字的组合查询功能。在使用该系统录入新书籍 时系统会自动按规则生成书号，可以修改信息，但不 能够删除记录。该系统还应该能够对书籍的外借情况 进行记录，可对外界情况列表打印。另外，还希望能 够对书籍的购买金额、册数按特定时限进行统计。
ReturnWithFine
40
(2)图书馆管理员处理借书、 还书的用例图
Login BorrowBook
UML建模与分析
<<include>> <<include>> ProcessOverTime DisplayLoans <<include>> Librarian ReturnBook <<include>> QueryLoanInfo <<include>>
第5章用例图-修订
用例
例如：网站后台管理系统中的会员信息维护用例，管理员需要进 行添加会员信息、修改会员信息、删除会员信息等操作。
还可以根据具体的操作把它抽象成3个用例，它展示的系统需求和 单个用例是完全一样的。
26
用例
用例规约
对于每一个用例，我们还需要有详细的描述信 息，以便让别人对于整个系统有一个更加详细 的了解，这些信息包含在用例规约之中。
8
概述
在用例建模中，为了更加清楚的描述用例或 者参与者，会使用到注释。
9
参与者
参与者是与系统、子系统或类发生交互作用 的外部用户、进程或其他系统的理想化概念。 作为外部用户与系统发生交互作用，这是参 与者的特征。
10
参与者
在系统的实际运作中，一个实际用户可能对 应系统的多个参与者。 不同的用户也可以只对应于一个参与者，从 而代表同一参与者的不同实例。
36
练习1
网络的普及带给了人们更多的学习途径，随之用来 管理远程网络教学的“远程网络教学系统”也出现。 “远程网络教学系统”的功能需求包括：
(1)学生登录网站后，可以浏览课件、查找课件、下载课 件、观看教学视频。 (2)教师登录网站后，可以上传课件、上传教学视频、发 布教学心得、查看教学心得、修改教学心得。 (3)系统管理员负责对网站页面的维护，审核不法课件和 不法教学信息，批准用户注册。
4
概述
用例图特点
用例图可视化地表达了系统的需求，具有直观、 规范等优点，克服了纯文字性说明的不足。 用例方法是完全从外部来定义系统功能，它把 需求和设计完全的分离开来。我们不用关心系 统内部是如何完成各种功能的，系统对于我们 来说就是一个黑箱子。
5
用例和用例图
访客用例图
会员用例图
书店管理员用例图
3、用例描述 （1）细化用例描述----搭框架
用例名称：搜索图书 概述：用户根据关键字搜索图书 前置条件：无 事件流： 基本事件流 扩展事件流 后置条件: 无
3、用例描述 （2）细化用例描述----填＂血肉＂
事件流： •基本事件流 1 用户点击“搜索图书”，用例开始。 2 系统显示搜索图书商品界面，提示用户输入商品关键字。 3 用户输入图书关键字，选择提交。 4 系统访问数据库，根据关键字查询相关的图书商品信息， 并把查询出的图书信息显示搜索图书页面。 5 用例结束。 •扩展事件流 4a) 系统未查出所要商品相关信息，显示提示信息，用例 结束。 4b) 系统查出用户输入的关键字为空，显示提示信息并返 回基本事件流2。
编写用例描述应遵循以下几点：
使用简单的语法，主语明确，语义易于理解；在事件流描 述中让读者直观地了解是参与者在控制还是系统在控制； 从第三者观察的角度指出参与者的动作，以及系统的响应； 显示参与者的意图而非动作 显示过程向前推移，每一步都有前进感；
构建结构良好的用例
为系统和部分系统中单个的、可标识的、合理的原子行为 命名。 将多个用例的公共的行为抽取出来放到一个被包含用例中。 对于变化部分，将其抽取出来，放到扩展用例中。 清晰的描述事件流。
扩展关系（Extend）
扩展关系表示基本用例在由扩展用例间接说明的一个位置 上隐式的合并了另一个用例（扩展用例）的行为。 基本用例不知道扩展用例的任何细节，没有扩展用例，基 本用例是完整的。只有在特定条件下，它的行为可以被扩 展用例的行为扩展，因此扩展关系处理事件流的异常或者 可选事件。
第5讲2-用例及用例图
a 经过读卡机，储户插入ATM卡
b ATM系统从卡上读取银行ID、帐号、并验证帐号。 c 储户键入密码，系统检验密码。 d 储户按确认键，输入取款金额。 e ATM把帐号和取款金额传递给银行系统，取回帐户余额。 f ATM输出现金，并显示帐户余额。 d ATM统计事务到日志文件。
参加者
1. 参加者旳概念 参加者（actor）是外部需要与系统交互旳事物。
也被称为活动者。 2.参加者旳三种类型
①. 人：客户，读者，库管员 ②. 设备：计算机，磁盘，读卡机等 ③. 外部系统：上层系统等
参加者旳表达
参加者能够表达为下面三种形式。
参加者之间旳关系
参加者之间能够有泛化关系。
用例之间旳关系(1)
用例之间能够具有下列几种关系：
➢ 泛化关系 ➢ 包括关系 ➢ 扩展关系
参加者与用例之间旳关系
关联关系 参加者与用例之间是关联关系，表达参加者与用
例之间具有使用，交互信息旳关联。
用例之间旳关系(3)
泛化关系 参加者与参加者之间，用例与用例之间存在一般与 特殊旳关系。
用例之间旳关系(4)
包括关系 两个用例之间，一种用例(基本用例)旳行为包括了 另外一种用例(包括用例)旳行为。 包括关系用依赖关系旳<<include>>构造型来表 达。
某学校网上选课系统旳用例分析(1)
管理员经过系统管理界面进入系统，建立本学期 要开设旳多种课程，将课程信息保存到数据库中， 并能够对课程进行改动和删除。 学生经过客户机浏览器进入系统，选择课程：能够 查询课程，选择课程，支付课程费用。
某学校网上选课系统旳用例分析(2)
●找出系统外部参加者，拟定系统边界和范围。
uml各种图例及说明
uml各种图例及说明1、用例图描述角色以及角色与用例之间的连接关系。
说明的是谁要使用系统，以及他们使用该系统可以做些什么。
一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。
2、类图类图是描述系统中的类，以及各个类之间的关系的静态视图。
能够让我们在正确编写代码以前对系统有一个全面的认识。
类图是一种模型类型，确切的说，是一种静态模型类型。
3、对象图与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。
它描述的不是类之间的关系，而是对象之间的关系。
4、活动图描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。
能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。
5、状态图描述类的对象所有可能的状态，以及事件发生时状态的转移条件。
可以捕获对象、子系统和系统的生命周期。
他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。
一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。
状态图是对类图的补充。
6、序列图（顺序图）序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。
顺序图可以用来展示对象之间是如何进行交互的。
顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。
7、协作图和序列图相似，显示对象间的动态合作关系。
可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。
如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。
8、构件图（组件图）描述代码构件的物理结构以及各种构建之间的依赖关系。
空间数据库
空间数据:用来描述空间实体的位置，形状，大小及分布特征诸多方面信息的数据，以及表示地丢表层一定范围的地理事物及其关系。
特点:A空间性表现力空间实体位置或所处地理位置。
空间实体几何特征及实体间的拓扑关系，从而形成了空间物体的位置形态，大小以及由此产生的一系列特征。
B专题性在一个坐标位置上地理信息具有专题属性数据，质量描述数据等。
如在一个地面店上，可取得高程，污染交通等专题属性C时间性指空间数据的空间特征和属性特征随时间的变化的动态变化特征，即时序特性。
空间数据库:是存放空间数据的数据库,更确切的说,是用来描述空间物体的位置数据,位置数据元素(点线面体)之间的拓扑关系以及描述这些物体的属性数据的数据库.典型应用:GIS. 摄影测量学,计算机图形学,遥感等学科.空间数据库的特点:A空间数据库用来管理的是现实世界中相关性大的连续数据,要求进行综合管理,通常在GIS分析中,需要综合运用实体之间的空间关系和属性数据.B 空间数据库描述的空间实体类型多,关系复杂,使数据模型复杂.C 空间数据库存储的空间数据具有非结构化特征,不满足关系型数据库的范式要求.空间数据库管理系统(SDBMS):主要功能是提供对空间数据和空间关系的定义和描述,提供对空间数据查询语言,实现对空间数据的高效查询和操作,提供对空间数据的存储和组织,提供对空间数据的直观显示等.基于对象-关系数据库管理系统(ORDBMS),OODBMS的SDBMS: A一个DBMS是一个软件模块,它利用一个底层数据库管理系统(如OODBMS,ORDBMS);B SDBMS支持各种空间数据模型,相应的空间数据类型(ADT)以及一种能够调用该种ADT的查询语言; C SDBMS支持空间索引,高效的空间操作算法以及用于查询优化的特定领域规则.在ORDBMS上搭建SDBMS的体系结构是一个三层体系结构,由左到右,顶层为空间应用,如GIS,MMIS,CID,该应用层并不直接与OR-DBMS打交道,而需要经过一个中间层与ORDBMS 交互,我们将这个中间层称为空间数据库(SDB),中间层是封装大多数只是的地方,并被插入到OR-DBMS中,如此对于称为空间数据库刀片,空间数据库暗箱,空间数据库引擎的商业OR-DBMS的产品也就不足为奇了.矢量数据交换格式(VCT)由以下六部分组成:A文件头B要素类型参数C属性数据结构D 几何图形要素E注记F属性数据其中,A文件头分为两类信息,一类是基本的必须的数据,不可缺省,如版本,坐标单位,坐标维数,矢量数据交换的格式的标志;另一类是扩充的附加信息,可省略B要素类型参数,定义前必须加上FeatureBegin和FeatureEnd作为要素类型参数的标志,而要素类型参数的中间不再需要写字符说明.FeatureBegin要素类型参数编码1,要素类型名称1,几何类型,属性表名,缺省颜色,用户项…..FeatureEndC 几何图形要素的存储包括点状要素格式,线状要素格式和面状要素格式.D注记信息紧跟几何图形数据,用AnnotationBegin和AnnotationEnd表示开始和结束.E属性数据所有要素的属性数据块都以AttributeBegin和AttributeEnd标识,每个要素的属性放在一行,相对集中.ArcView的Shapefile文件格式:ShapeFile是ArcView的原生数据格式,属于简单要素类,用点线多边形存储要素的形状,但不能用于存储拓扑关系,具有简单.快速生成的优点.在Shapefile中的信息可以分为两种类型:一种与数据有关,如主文件的记录信息,主文件文件头有关数据描述的字段;一种与数据的组织格式有关,如文件和记录的长度和记录的偏移等.这些信息是以文件的方式进行存储,每个Shapefile文件至少含有三个文件.shp主文件,.shx索引文件,.dbase表文件即.pdf,其中主文件和索引文件是二进制文件,表文件是数据库文件.A主文件主要存储Shapefile的图形数据,每个祝文件爱你包括一个固定长度的文件头和不固定长度的记录.如下表组成:①在主文件中,文件头和记录信息是由整型和双精度整型由小到大的字节顺序组成的数据描述字段,其余有关文件和文件组织管理信息是由整型和双精度浮点型由大到小的字节顺序组成的数据描述字段.②记录头主要存储了每条记录的记录号和记录信息的长度③记录信息是由图形类型和图形的空间数据组成.8字节的记录组成Array①文件头,其签32字节是文件的整体描述,接着美32字节定义一个字段直至碰到0ah,从第32字节到0ah为止是字段描述区②第二部分实存储的是每一个记录的数据部分,紧接着文件头存储的数据记录,记录以定长格式顺序存储.空间数据库引擎：(SDE)是空间数据库管理的重要基础技术，从用户的角度看，SDE 是用户与异构空间数据库之间的接口；从软件的角度看，SDE是应用程序和RDBMS 之间的中间体，用来管理空间数据库；从系统的角度看，SDE利用RDBMS和其扩展功能，实现空间数据在数据库中的物理存储。
02 UML用例图基础知识
表示符号
表示参与者与用例之间的通信，任何一方都可发送 或接收消息。
uc 继承关系，子用例将继承基用例 的所有行为、关系和通信关系，也就是说在任何使 用基用例的地方都可以用子用例来代替。
泛化关系在用例图中使用空心的箭头表示，箭头方 向从子用例指向基用例。 uc Use Case Model
参与者总是处在正在建模的系统的外部，不是系统
的组成部分，是与系统、子系统或类发生交互的外 部用户、进程或其他系统。
参与者有3大类，即系统用户、与本系统交互的其 他系统和一些可以运行的进程。
名称
说明
人
即用户，是最常用的参与者。例如，汽车租赁公司的汽车租赁者，即客
户。
其他的系统
在当前的项目范围外，建立与其他系统的接口。该类位于程序边界之外
注：任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的
用例。
2）用例图形表示
在UML中，用例使用一个椭圆来表示，用例的名称写在椭圆里，如 下图所示：
3）用例命名
用例是从用户的角度来描绘系统的功能，是根据所执行的实例来命名 的，通常情况下，用例名是一个短语，例如浏览帐户、登陆系统等。 命名的基本原则有以下几种：
一、什么是用例图（Use Case Diagram） 二、用例图的组成 三、用例建模技术
用例图也称为用户模型图，是由软件需求分析到最终实现的第1步， 它是从用户的角度来描述系统功能，描述人们希望如何使用一个系统。 用例图显示谁将是相关的用户、用户希望系统提供什么服务，以及用 户需要为系统提供的服务。
线上标注<u<c Usee CaxsetMoedenl d>>)，箭头从子用例指向基用
例。
用例和用例图
如何绘制用例图 1、用例分析技术步骤（不固定，可根据需要调整）：
⑴ ⑵ ⑶ ⑷ ⑸ ⑹ ⑺ 找出系统外部的参与者和外部系统，确定系统的边界和范围。 确定每一个参与者所期望的系统行为 把这些系统行为命名为用例 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分 编制每一个用例的脚本 绘制用例图 区分基本事件流和异常情况的事件流，如有需要可以把表示异常 情况的事件流作为单独的用例来处理 ⑻ 细化用例图，解决用例间的重复与冲突。
用例之间的关系 4、参与者与用例之间的关系：关联关系Association
关联关系描述参与者与用例之间的关系，在UML中它是 两个或多个类元之间的关系，它描述了类元的实例间的 联系。(类元，一种建模元素，常见类元包括类、参与者 、构件、数据类型、接口、结点、子系统以及用例等， 其中类是最常见的类元) 关联关系表示参与者和用例之间的通信。在UML中，关 联关系用直线或箭头表示。如果参与者启动了用例，箭 头指向用例；如果参与者利用了用例提供的服务,箭头指 向参与者。如果二者是互动的，则是直线。 例：汽车租赁系统用例图(部分)。显示的是“客户”参与者以 及与他交互的3个用例，“预定”、“取车”、“还车” 。
FEAT01.新增书籍信息 FEAT03.书籍信息按计算机类、非计算机类分别建档 FEAT04.录入新书时能够自动按规则生成书号 FEAT05.计算机类与非计算机类书籍采用不同的书号规则 FEAT06.录入新书时如果重名将自动提示 FEAT02.修改已有的书籍信息 FEAT07.按书名、作者、类别、出版社等关键字组合查询书籍 FEAT08.列出所有书籍信息 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 FEAT09.记录外借情况 FEAT10.外借状态能够自动反应在书籍信息中 FEAT11.按人、按书查询外借情况 FEAT12.列出所有的外借情况 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 FEAT13.按特定时间段统计购买金额、册数 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行
软件工程-论文-用例图-需求分析-项目流程图--实例图---RE图--属性图
药品管理系统1。
简要这次是C＃考试答辩程序改写有不足望老师见谅：经过市场调研，初步了解到药品销售管理系统在现实生活中的应用，现行的医药管理系统在现实中的应用主要是药品的收费管理和药品销售的账目管理,药品的库房管理（药品的进库，药品的出库）其中，最常用的是，销售管理和库房管理。
此系统操作性相对简单，只要对电脑有一定操作基础的人员都可以使用，系统对用户的提示性较好，可以提醒和引导用户对系统的操作。
本课题通过对现行医药管理信息系统的组织结构，业务流程,数据库等进行研究,分析系统的实际运行情况，并提出新的逻辑设计方案，以此来完善改进现有的系统，这对于医药企业提高经营管理具有一定的积极意义.2.简要说明本用例是一个医药超市管理系统，只有管理员和销售员有管理权限，其中管理员和销售员可以对自己的密码进行修改。
用用自己的管理账号对医药进行管理，进货销售等等.3需求3。
1医药销售管理系统需求分析以往到药店购买药品的时候，销售人员都要手写单据和人工结账，而且每天都要统计当日的销售额，月末要统计一个月的销售额,所以要管理大量的单据，而且在统计的时候需要大量的时间，并且是人工操作，比较容易出错。
医药管理系统的出现，使得这一切变得简单起来。
以往需要算一个小时的账目现在只需点一下鼠标就可以得到，而且得到的结果还是精确的，不用担心有错误，用电脑代替人脑计算,为使用者节省了大量时间。
另外消费者也得到了便利，因为键盘录入取代了手写的单据增加了效率,在我们购买药品的时候也就方便了起来.信息管理系统的出现,改变了企业的管理模式，药品销售管理系统则改变了医药行业的管理模式。
在当今医药行业，一套好的销售管理系统成为众多企业的得力助手。
3。
2 医药销售管理系统数据库医药销售管理系统是基于网络应用,根据医药销售系统的长期开发研究经验和各医药公司现实中存在的实际业务情况,完全采取面向对象的系统开发方法,进行严格设计而成的专业医药销售管理软件。