软件工程-用例图
软件工程---交互建模之交互图,顺序图与协作图
2.5 消息
格式
[前缀][守卫条件][顺序表达式][返回值:=]消息名([参数列表])
例：
2: display ()
简单消息
1.3.1: p:=find()
带返回值的嵌套消息
[x<0] 4: invert(x, color) 条件消息
3.1 *[x = 1..10] : update() 循环消息
[ 条件子句 ] 条件子句一般用来表示分枝而不是用作守卫条件[x<0]是两个可
以用来分枝的条件子句这两个条件只能有一个为真因而只有一 个分枝被执行(即发送与分枝有关的消息) 条件子句和循环子句都可以用伪代码或真正的编程语言来表示 序列表达式用冒号结束
返回值、消息名和参数表
返回值表示一个操作调用(即一个消息)的结 果
顺序图中消息编号可显示，也可不显示。 协作图中必须显示Procedure Call） 异步（Asynchronous） 返回（Return） 自关联消息（Self Message）
2.5 消息
UML三种消息：
调用（Procedure Call） 发送者把消息发送后，等待直到接收者返回控制， 可以表示同步(synchronous message)； 实心箭头符号
包括对象名和类名 类名（匿名对象） 对象名（不关心类）
2.3 生命线
生命线（Lifeline）：
每个对象都有自己的生命线，用来表示在该用例中一个对象在一段时 间内的存在
垂直的虚线 如果对象生命期结束， 则用注销符号表示 对象默认的位置在图 顶部，表示对象在交互 之前已经存在 如果是在交互过程中 由另外的对象所创建， 则位于图的中间某处。
顺序图
面向时间描述对象交互的图
协作图
UML用例图的画法
一．UML简介UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。
它融入了软件工程领域的新思想、新方法和新技术。
它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。
其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。
二．用例建模简介用例建模是UML建模的一部分，它也是UML里最基础的部分。
用例建模的最主要功能就是用来表达系统的功能性需求或行为。
依我的理解用例建模可分为用例图和用例描述。
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
用例描述用来详细描述用例图中每个用例，用文本文档来完成。
1．用例图参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。
参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
这是UML对用例的正式定义，对我们初学者可能有点难懂。
我们可以这样去理解，用例是参与者想要系统做的事情。
对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。
用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
实验报告1--用例和用例图
中北大学软件学院实验报告
专业：软件工程
方向：软件开发与测试
课程名称： UML
班级：
学号：
姓名：
辅导教师：井超
2017年3月制
4.用例图如下所示
1).系统参与者
系统角色
2).图书管理
图书管理用例图3).图书借阅和还书用例图
图书的借阅和归还用例4).图书管理系统的整体用例图
图书管理系统的整体用例图
5.实验结论及心得
通过本次实验，我掌握了在课堂上学习的用例图等。
加深了对书本知识的认识和记忆。
在实验中我学会了去如何操作ro se工具图。
通过ro se工具图，可以去清晰的去展示一个关系等。
使用非常方便。
uml相关的名词解释
uml相关的名词解释UML（统一建模语言）相关名词解释简介：在软件工程中，统一建模语言（UML）是一种标准化的、通用的建模语言，用于描述和构建软件系统。
被广泛应用于软件开发过程中的需求分析、系统设计、代码生成等环节，UML具备描述问题领域、定义软件结构和行为的能力，以及促进开发者之间的交流和沟通。
本文将对与UML相关的一些关键名词进行解释与阐述。
1. 用例图（Use Case Diagram）用例图是UML中最常用的图形之一，用于描述系统与用户之间的交互。
用例图通过显示系统的功能和角色之间的关系，来帮助开发者理解和定义系统的需求。
用例图中的参与者代表系统的用户、外部组织或其他系统，而用例则代表系统的功能或交互场景。
用例图可以帮助团队更好地理解系统的需求，从而指导系统的设计和开发过程。
2. 类图（Class Diagram）类图是用于描述系统中的类、接口、关系和结构的图形化工具。
在类图中，类被表示为矩形框，类之间的关系以及类的属性和方法则通过箭头连接来表示。
类图可以帮助开发者理解、设计和组织系统中的类与对象之间的结构关系，从而更好地进行系统设计和编码。
3. 时序图（Sequence Diagram）时序图用于描述对象之间的交互，尤其是强调交互的顺序和时序逻辑。
时序图中的对象以及它们之间的消息传递被表示为垂直的时间轴和消息顺序。
时序图可以帮助开发者理解和描述系统中对象之间的交互过程，以及时间上的先后关系。
4. 活动图（Activity Diagram）活动图用于描述系统中的行为和流程，强调系统中的活动和动作。
活动图以节点和边的形式描述活动的流程和顺序，用于展示系统中各个活动之间的流转和控制。
活动图可以帮助开发者分析和设计系统中的流程，以及理解系统的行为逻辑。
5. 组件图（Component Diagram）组件图用于描述系统的组件和它们之间的关系，关注系统的组织结构和组件之间的依赖关系。
在组件图中，组件被表示为矩形框，组件之间的关系以及组件的接口则使用箭头表示。
软件工程,论文 用例图 需求分析 项目流程图 实例图 RE图 属性图讲解
药品管理系统1.简要这次是C#考试答辩程序改写有不足望老师见谅:经过市场调研，初步了解到药品销售管理系统在现实生活中的应用，现行的医药管理系统在现实中的应用主要是药品的收费管理和药品销售的账目管理，药品的库房管理（药品的进库，药品的出库）其中，最常用的是，销售管理和库房管理。
此系统操作性相对简单，只要对电脑有一定操作基础的人员都可以使用，系统对用户的提示性较好，可以提醒和引导用户对系统的操作。
本课题通过对现行医药管理信息系统的组织结构，业务流程，数据库等进行研究，分析系统的实际运行情况，并提出新的逻辑设计方案，以此来完善改进现有的系统，这对于医药企业提高经营管理具有一定的积极意义。
2.简要说明本用例是一个医药超市管理系统，只有管理员和销售员有管理权限，其中管理员和销售员可以对自己的密码进行修改。
用用自己的管理账号对医药进行管理，进货销售等等。
3需求3.1医药销售管理系统需求分析以往到药店购买药品的时候，销售人员都要手写单据和人工结账，而且每天都要统计当日的销售额，月末要统计一个月的销售额，所以要管理大量的单据，而且在统计的时候需要大量的时间，并且是人工操作，比较容易出错。
医药管理系统的出现，使得这一切变得简单起来。
以往需要算一个小时的账目现在只需点一下鼠标就可以得到，而且得到的结果还是精确的，不用担心有错误，用电脑代替人脑计算，为使用者节省了大量时间。
另外消费者也得到了便利，因为键盘录入取代了手写的单据增加了效率，在我们购买药品的时候也就方便了起来。
信息管理系统的出现，改变了企业的管理模式，药品销售管理系统则改变了医药行业的管理模式。
在当今医药行业，一套好的销售管理系统成为众多企业的得力助手。
3.2 医药销售管理系统数据库医药销售管理系统是基于网络应用，根据医药销售系统的长期开发研究经验和各医药公司现实中存在的实际业务情况，完全采取面向对象的系统开发方法，进行严格设计而成的专业医药销售管理软件。
软件工程用例图
第5页/共27页
用例图的构成要素
2. 参与者间的关系
• 由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主 要是泛化关系（或称为“继承”关系）。
第18页/共27页
使用Rose创建用例的步骤说明
2. 识别参与者
• 对于一个学校来说，最重要的就是教育学生成才，所以我们首先要考虑到的参与者就是 学生。
• 要给学生上课，必然就需要教师。教师负责教育学生、并且在日常管理中可以查询学生 的基本信息、查询学生的考试成绩。
• 作为一个学校，除了教师和学生，还有不可或缺的就是校领导。为了便于校领导掌握学 校的基本情况，加强对学校的管理导.
改教学心得。 (3)系统管理员负责对网站页面的维护，审核不法课件和不法教学信息，批准用户注册。
第24页/共27页
练习题
（1）学生需要登录“远程网络教学系统”后才能正常使用该系统所有 功能。如果忘记密码，可以通过“找回密码”功能找回密码。登录 后学生可以浏览课件、查找课件、下载课件、观看教学视频，请画 出学生参与者的用例图。
第20页/共27页
使用Rose创建用例的步骤说明
• 教师参与用例录入 成绩、修改成绩、 保存成绩、查询成 绩、删除成绩和登 录。学生参与用例 登录和查询成绩。 因为修改成绩和录 入成绩的时候都要 保存成绩，所以将 保存成绩抽象出来 作为单独的一个用 例。用例录入成绩、 修改成绩和用例保 存成绩之间是包含 关系，用例找回密 码和用例登录之间 是扩展关系。
• 系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此，系统与系统之间需要使 用系统边界进行区分开来。我们把系统边界以外的同系统相关联的其他部分，称之为系统环境。
软件工程9种图
软件工程9种图软件工程9种图本文档旨在介绍软件工程中常用的9种图，包括需求分析图、用例图、活动图、类图、状态图、序列图、通信图、部署图和物理架构图。
每个章节将详细说明各种图的定义、特点和使用方法。
1.需求分析图需求分析图主要用于描述系统的需求和功能，并将其转化为可视化的图形表示。
它包括用例图、活动图、状态图等多种子图。
用例图用于展示系统的功能、用户以及各功能之间的关系；活动图则表示系统中的各种活动以及它们之间的关系；状态图则描述系统中对象的不同状态和状态之间的转移。
2.用例图用例图是描述系统功能和用户之间交互的图表。
它展示了系统的功能性需求，包括系统的主要功能和参与者（用户）之间的关系。
用例图由参与者、用例和关系构成，通过参与者和用例之间的关系来表示用户与系统的交互。
3.活动图活动图用于描述系统中的活动或业务流程，以及这些活动之间的顺序关系。
它展示了系统的业务流程，包括活动、决策、并行和合并分支。
活动图通过节点、边和分支条件来表示活动之间的关系。
4.类图类图用于描述系统中的类、对象以及它们之间的关系。
它展示了系统的结构，包括类的属性、方法、关联关系、继承关系等。
类图通过类、对象、关联和继承等元素来表示系统的结构。
5.状态图状态图用于描述系统中对象的不同状态和状态之间的转移。
它展示了系统中对象的状态及其变化，包括对象的初始状态、中间状态以及最终状态。
状态图通过状态、转移和条件来表示对象的状态和状态之间的转移。
6.序列图序列图用于描述系统中对象之间的交互顺序和消息传递。
它展示了系统中对象之间的交互流程，包括对象的创建、销毁、方法调用等。
序列图通过对象、消息、生命线等元素来表示对象之间的交互和顺序关系。
7.通信图通信图用于描述系统中对象之间的交互和消息传递。
它展示了对象之间的通信方式，包括消息的发送和接收。
通信图通过对象、消息、连接线等元素来表示对象之间的交互和通信关系。
8.部署图部署图用于描述系统中软件和硬件组件的部署布局。
软件工程用例模型分析
一个用例是可以被行为 者感受到的、系统的一 use case 个完整的功能。 参与者是指在系统之 外，透过系统边界与系 Actor 统交互的任何事物，代 表外部实体。可能是人、 用例之间的关系有：扩 另外一个系统、时间的 展关系、使用关系和泛 流逝等。 化关系。 系统是提供用例的黑盒 子。其边界用矩形框表 示，用例图中也可不画 系统边界。
面向对象方法引论—用例模型
信息工程学院
参与者的泛化
参与者之间也可以象类一样存在泛化或者依 赖关系。
用户 登录系统
选课
学生
教师
安排教学计划
面向对象方法引论—用例模型
信息工程学院
识别用例时需要思考的问题
每个参与者的任务是什么 由参与者将要创建、存储、改变、删除或读取系统中 的信息吗 什么用例会创建、存储、改变、删除、或读取这个信 息 参与者需要通知系统外部的变化吗 需要通知参与者系统中正在发生的事情吗 什么用例将支持和维护系统 所有的功能需求都能被用例执行吗
信息工程学院
面向对象方法引论—用例模型
例1：识别参与者
寻呼台系统：用户如果预定了天气预报，系 统每天定时给他发天气消息；如果当天气温 高于35度，还要提醒用注意防暑；
在这个叙述里，谁是寻呼台系统的Actor？
面向对象方法引论—用例模型
信息工程学院
预定天气预报
用户
发送天气预报
时间
提醒防暑
温度
寻呼台系统用例图
<<extend>>
面向对象方法引论—用例模型
软件工程---UML动态分析-活动图
Make Plan
entry/ SetGoal
2020/5/4
26
动作流
与状态图不同，活动图的转换一般都不需要特 定事件的触发。
一个动作状态执行完本状态需要完成的动作后 会自发转换到另外一个状态。
2020/5/4
27
动作流
一个活动图有很多动作或者活动状态，
活动图通常开始于初始状态，然后自动转换到 活动图的第一个动作状态，一旦该状态的动作 完成后，控制就会不加延迟地转换到下一个动 作状态或者活动状态。
7
活动图与流程图的区别
⑴ 流程图着重描述处理过程，它
的主要控制结构是顺序、分支 和循环，各个处理过程之间有 严格的顺序和时间关系
找饮料 [ 发现咖啡 ]
活动图描述的是对象活动的顺序
把咖啡放入 滤器
关系所遵循的规则，它着重表 将滤器放入 现的是系统的行为，而非系统 机器
的处理过程。
往容器里加 水
开机器
活动图着重表现从一个活动到另一个活动的控制流， 是内部处理驱动的流程。
找饮料
[ 发现咖啡 ]
[ 没有咖啡 ] [ 发现可乐 ]
把咖啡放入 滤器
往容器里加 水
拿茶杯
拿可乐
将滤器放入 机器
[ 没有可乐 ]
开机器 冲咖啡
倒咖啡
喝饮料
2020/5/4
12
活动的图形表示
在UML中，活动表示成圆角矩形，与状态的圆角矩 形相比，活动的矩形的圆角更柔和，看上去接近椭 圆。
不能中断，一直运行到结束。 ⑶ 动作状态是瞬时的行为，它所占用的处理时
间极短，有时其至可以忽略。
2020/5/4
19
动作状态
动作状态有如下特点：
第2章用例图
ReturnBook
Maintenance
用例的泛化
分层泛化
Management System
ReturnBook BorrowBook Maintenance
Maintenance BorrowerInfo
Maintenance BookInfo
2.1.4 用例与参与者的关系 用例与参与者之间的关系(通信)是双向的
2.5.2
确定系统的参与者
首先分析系统所涉及的问题领域和系统运行 的主要任务： ① 分析使用该系统主要功能部分的是哪些人。 ② 谁将需要该系统的支持以完成其工作。 ③ 系统的管理者与维护者。
2.5.2
确定系统的参与者
详细需求列表 系统可以完成学生借书和还书请求 系统允许学生浏览借阅信息 如果学生超期未还，系统生成一个超期罚款信息 图书信息需要维护 学生信息需要维护 图书管理员信息需要维护 系统需要维护
2.4.2 扩展关系
扩展用例的启用机制：扩展点 扩展点：基用例中的一个或多个位置，在该位 置会衡量某个条件以决定是否启用扩展用例 图2-21
泛化、包含与扩展关系的区别
泛化与包含用例属于无条件发生的用例，而扩展属 于有条件发生的用例。 泛化侧重表示子用例间的互斥性、用例间的继承性； 当两个或者多用例在行为，结构和目的方面存在共 性时，就可以使用泛化关系 包含侧重表示被包含用例提供服务的复用性； 扩展侧重表示扩展用例的触发不定性（可选性）；
用例图的组成 理解泛化 理解用例之间的关系 对用例进行描述 绘制用例图
3
2.1
用例图的构成
用例图用于定义系统的功能需求，它描述了系统的参与者 与系统提供的用例之间的连接关系。这里的参与者可以人， 也可以另一个系统。用例图仅从参与者使用系统的角度描 述系统中的信息。下图描述了一个学生成绩管理系统的用 例图。
软件工程中的软件需求分析方法(二)
软件工程中的软件需求分析方法导言在软件开发过程中，准确、清晰的软件需求分析是成功的关键。
软件需求分析方法的选择和运用，对于确保软件项目的顺利进行以及最终交付优质产品具有重要意义。
本文将探讨几种常见的软件需求分析方法，并介绍它们各自的优缺点。
1. 需求采集方法用户需求访谈用户需求访谈是一种常用的需求采集方法。
通过与终端用户直接交流，软件开发团队能够深入了解用户的需求、期望和挑战。
然而，这种方法的一个限制是，用户在开始的时候可能并不清楚自己具体需要什么，或者无法表达清晰的需求。
场景分析场景分析方法通过模拟真实的使用场景，帮助开发团队了解用户在实际情况下的需求。
开发团队可以通过观察用户在特定场景下的行为、交互等来推断出软件的需求。
然而，这种方法可能无法覆盖所有的使用场景，并且可能受到开发团队的主观因素的影响。
2. 需求建模方法用例图用例图是一种常见的需求建模方法，用于描述软件系统与其用户之间的交互。
它通过标识不同用户角色和系统功能，揭示系统的需求和行为。
用例图直观地展示了系统的功能和交互，有助于软件开发团队更好地理解用户需求。
然而，用例图不能提供详细的需求规范，无法满足复杂系统的需求分析。
数据流图数据流图是一种将系统视为一系列信息流动的图形表示方法。
它描述了软件系统中数据的流动路径和处理过程。
通过数据流图，开发团队可以更好地理解系统中不同模块的功能和相互关系，从而推导出详细需求。
然而，数据流图可能过于复杂，导致需求分析变得困难。
3. 需求验证方法原型验证原型验证方法通过制作出初步的系统原型，让用户提供反馈并验证软件需求的准确性。
原型验证可以帮助开发团队更好地理解用户需求，及时发现和修复问题。
然而，原型开发需要一定的时间和资源投入，并且可能导致需求变更频繁。
领域专家评审领域专家评审是一种常见的需求验证方法。
通过邀请相关领域的专家对需求规格文档进行评审，开发团队可以快速发现和纠正潜在的问题和风险。
然而，依赖专家的评审可能受到时间和资源的限制，评审结果也可能受到主观因素的影响。
软件工程_综合题2
平时作业和2010两张卷子里的综合题作业2：类图、对象模型、用例图（1）类图（使用对象模型描述类对象所具有的属性，以及公司类对象提供的服务）依赖，聚合依赖：①《include》包含依赖：源包含目的②《extend》扩展依赖：源是目的的扩展。
聚合：共享，整体消失后部分仍然存在。
复合：部分与整体的关系，整体消失后部分也消失。
关联，复合关联、继承（泛化）关联、依赖（2）对象图书p81①对象名：类名②属性=属性值③对象间的链可以使类之间关联的实例（3）对象模型对象模型的描述工具：对象图。
0，1：表示有0个或1个。
1+：表示多个不写：表示有且仅有一个。
（4）用例图（参与者，用例,调用关系）画图步骤：(a)(b)(c)(d)作业3：Jackson系统方法（用jackson图可以表示数据结构、程序结构）参考：jackson作业试用Jackson方法编写一程序，要求能依次完成下列工作：——统计起始卡以前的卡片张数，存入A；——打印起始卡的内容；——统计起始卡以后出现的K1卡和K3卡总批数，存入B；——统计起始卡以后出现的K1卡的张数，存入C；——统计起始卡以后出现的K3卡的批数，存入D；——打印终了卡的内容；——打印A，B，C，D 4个统计值。
第一步：画出数据结构图第二步：画程序结构图（基于数据结构图画）第三步：写出程序的过程性表示（伪码）打开卡片文件;读卡片;A:=0;处理前置部分iteruntil出现K1卡;处理非K1卡seqA:=A+1读卡片;处理非K1卡end;处理前置部分end;打印起始卡;B:=0;C:=0;D:=0;读卡片;处理批部分iteruntil出现K2卡;处理批seq统计总批数; {B:=B+1}处理批类select是K1卡处理K1批iterwhile出现K1卡;处理K1卡seqC:=C+1;读卡片;处理K1卡end;处理K1批end;处理批类or是K3卡处理K3批seq;D:=D+1;处理批体iterwhile出现K3卡;读卡片;处理批体end;处理K3批end;处理批类end;处理批end;处理批部分end;打印终止卡;打印A,B,C,D;关闭卡片文件;卡片分析程序end；作业4：画出数据流图（DFD）。
《软件工程》第3章用例图及其应用
用例图的概念和作用
用例图是一种描述系统功能和用户行为的图形化工具。它帮助开发人员和利 益相关者理解系统的需求，并作为沟通和验证的工具。用例图能够直观地展 示系统功能，帮助识别系统的边界和行为。
用例图的基本元素
用例图包含参与者、用例和关系三个基本元素。参与者代表系统的外部角色， 用例代表系统的功能或服务，而关系则表示参与者和用例之间的交互和依赖 关系。
用例图的符号和表示方法
用例图使用参与者图标、椭圆形表示的用例以及连接线表示关系。参与者图标通常表示为人的图 标，用例图标则是一个椭圆形，并用文字描述用例的名称。
用例图在软件工程中的重要性
用例图在软件工程中起到了至关重要的作用。它不仅帮助开发人员了解系统 需求和功能，还能够引导需求分析和测试的工作，并作为可视化的沟通工具， 促进不同角色之间的合作交流。
结论
用例图作为软件工程中常用的建模工具，具有直观、易理解的特点。通过用例图，我们能够更好 地理解和沟通系统需求，提高系统开发的质量和效率。
用例图的绘制步骤
绘制用例图的步骤包括：确定系统的边界和参与者、识别系统的用例、绘制参与者和用例的图标、 添加关系和标注信息、进行审查和验证。
用例图的应用场景
用例图在软件工程中有广泛的应用场景，例如需求分析、系统设计、测试规 划等。通过用例图，开发人员和利益相关者能够共同理解系统功能和用户需 求，从而有效地进行软件开发。
软件工程课件之第4章用例和用例图
4.2.3 泛化关系
借阅者
.9 泛化关系
4.2.4 分组关系
在一些用例图中，用例的数目可能很多，这时就需要把 这些用例组织起来。这种情况在一个系统包含很多子系 统时就会出现。另一种可能就是，当你按顺序和用户会 谈，收集系统需求时，每个需求必须用一个单独的用例 来表达，这时就需要某种方式来对这些需求进行分类。
4.1.1 参与者
例如，在“图书管理系统”中，可以认为“读者”是 “学生读者”和“教师读者”的泛化，而“学生读者” 还可以具体化为“本科生读者”和“研究生读者”；同 样，“图书管理员”也是“采购员”、“ 编目员”及 “借阅人员”的泛化。图4.3表示出了参与者之间的泛 化关系。
4.1.1 参与者
“<<extend>>”是扩展关系的构造型，箭头指向基本用例。
4.2.2 扩展关系
借阅者
<<include>>
还书
<<extend>>
查询图书 交罚款
图4.8 扩展关系
区别与联系：
联系：都是从现有的用例中抽取出公共的那部分信息
，作为一个单独的用例，然后通过不同的方法来重用这 个公共的用例，以减少模型维护的工作量。
因此，在“图书管理系统”中“借阅者”和“系统管理 员”都是参与者。
4.1.1 参与者
【例4-1】客户给销售员发来传真订货， 销售员下班前 将当日订货单汇总输入系统。谁是系统的参与者？
分析：根据参与者的定义可知，此系统的参与者是销售 员。
4.1.1 参与者
【例4-2】在需求分析中常见的权限控制问题，一般的 用户只可以使用一些常规的操作，如查询等，而管理员 除了常规操作之外还需要进行一些系统管理工作，如一 些关键数据的增加、删除、修改等，操作员既可以进行 常规操作又可以进行一些配置操作。
《软件工程》第3章用例图及其应用
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一，它能 够帮助开发团队更好地理解用户需求，明确系统 的功能范围。
2
通过用例图，开发团队可以对系统的交互方式进 行模拟和验证，从而发现潜在的问题和缺陷，提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中，保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率，确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例，可以找出未被测 试到的功能和业务流程，从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率，降低 漏测的风险。
02
针对每个测试场景，细化出具体的测试用例，包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求，从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程，为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系， 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物，它描 述了用户期望的系统功能和行为。
02 在系统设计完成后，可以通过与原始用例图进行 对比，验证设计是否满足原始需求。
03 如果设计不符合原始需求，则需要重新调整设计， 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
UML各种图总结-精华
UML各种图总结-精华UML（UnifiedModelingLanguage）是一种统一建模语言，为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
下面将对UML的九种图+包图的基本概念进行介绍以及各个图的使用场景。
一、基本概念如下图所示，UML图分为用例视图、设计视图、进程视图、实现视图和拓扑视图，又可以静动分为静态视图和动态视图。
静态图分为：用例图，类图，对象图，包图，构件图，部署图。
动态图分为：状态图，活动图，协作图，序列图。
1、用例图（UseCaseDiagrams）：用例图主要回答了两个问题：1、是谁用软件。
2、软件的功能。
从用户的角度描述了系统的功能，并指出各个功能的执行者，强调用户的使用者，系统为执行者完成哪些功能。
2、类图（ClassDiagrams）：用户根据用例图抽象成类，描述类的内部结构和类与类之间的关系，是一种静态结构图。
在UML类图中，常见的有以下几种关系:泛化（Generalization）,实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)。
各种关系的强弱顺序：泛化=实现>组合>聚合>关联>依赖2.1.泛化【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何继承父类的所有特征和行为。
例如：老虎是动物的一种，即有老虎的特性也有动物的共性。
2.2.实现【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现。
2.3.关联【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。
双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
【代码体现】：成员变量2.4.聚合【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。
软件工程-论文-用例图-需求分析-项目流程图--实例图---RE图--属性图
药品管理系统1。
简要这次是C＃考试答辩程序改写有不足望老师见谅：经过市场调研，初步了解到药品销售管理系统在现实生活中的应用，现行的医药管理系统在现实中的应用主要是药品的收费管理和药品销售的账目管理,药品的库房管理（药品的进库，药品的出库）其中，最常用的是，销售管理和库房管理。
此系统操作性相对简单，只要对电脑有一定操作基础的人员都可以使用，系统对用户的提示性较好，可以提醒和引导用户对系统的操作。
本课题通过对现行医药管理信息系统的组织结构，业务流程,数据库等进行研究,分析系统的实际运行情况，并提出新的逻辑设计方案，以此来完善改进现有的系统，这对于医药企业提高经营管理具有一定的积极意义.2.简要说明本用例是一个医药超市管理系统，只有管理员和销售员有管理权限，其中管理员和销售员可以对自己的密码进行修改。
用用自己的管理账号对医药进行管理，进货销售等等.3需求3。
1医药销售管理系统需求分析以往到药店购买药品的时候，销售人员都要手写单据和人工结账，而且每天都要统计当日的销售额，月末要统计一个月的销售额,所以要管理大量的单据，而且在统计的时候需要大量的时间，并且是人工操作，比较容易出错。
医药管理系统的出现，使得这一切变得简单起来。
以往需要算一个小时的账目现在只需点一下鼠标就可以得到，而且得到的结果还是精确的，不用担心有错误，用电脑代替人脑计算,为使用者节省了大量时间。
另外消费者也得到了便利，因为键盘录入取代了手写的单据增加了效率,在我们购买药品的时候也就方便了起来.信息管理系统的出现,改变了企业的管理模式，药品销售管理系统则改变了医药行业的管理模式。
在当今医药行业，一套好的销售管理系统成为众多企业的得力助手。
3。
2 医药销售管理系统数据库医药销售管理系统是基于网络应用,根据医药销售系统的长期开发研究经验和各医药公司现实中存在的实际业务情况,完全采取面向对象的系统开发方法,进行严格设计而成的专业医药销售管理软件。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
北京建筑工程学院
理学院实验报告
课程名称软件工程实验名称用例图实验地点网三小日期2102-10-9
姓名王杰班级信09-1 学号2108190911211 指导教师张长伦王恒友成绩
【实验目的】
通过本次试验使学生掌握UML建模语言的基础知识和visio软件的基本用法，并进一步熟练掌握绘制用例框图基本步骤和方法。
【实验要求】
根据实验题目内容，完成相应的实验任务。
【实验内容】（主要包含问题分析、实验步骤、实验结果等，按课程要求完成）
1.一个新的音像商店准备采用计算机系统向比较广泛的人群销售或租借录像带和光碟。
该音
像商店将存有大约1000 盘录像带和500 张光碟，所有的录像带和光碟都有一个条码，可以使用条码扫描仪来支持销售和返还，客户会员卡也同时条码化。
客户可以预定录像带并在指定日期来取。
系统必须拥有灵活的搜索机制来回答客户的询问。
根据上述描述，请你给出音像租赁销售系统的用例模型。
2.参考答案及解题步骤
（1）系统用例：
a.识别系统角色和边界：
(a) 系统角色：客户
b.识别用例：
(a)事件：租赁录像制品、购买录像制品、订购录像制品、询问录像制品
(b)用例：租赁录像制品、购买录像制品、订购录像制品、询问录像制品
c.详述用例
(b)书写用例文档（任意挑选一个用例，书写用例文档）
(c)通过关系整理并排序业务用例
d.建立用例模型（绘制用例框图）
3. 用例文档 UC1：查询录像制品
执行者
客户
前置条件
客户音像租赁销售系统
后置条件
系统扫码确认客户信息
涉众利益
客户——希望查询到想要找的影碟。
商家——希望尽可能的满足客户的查询需求。
基本路径
a.客户输入查询结果。
b.系统显示查询结果。
扩展
客户查询不到结果
1)系统查询逼到结果。
2)提示用户重新搜索。
字段列表
查询信息包括：影碟名称、演员姓名、发行日期。
业务规则
影碟名称或者演员姓名必须写。
非功能需求
设计约束
客户必须先进行扫码才能进行查询操作。
待解决问题
搜索功能有待完善
实验截图：
【实验小结】（主要包含实验心得等）
通过本次试验使我掌握UML建模语言的基础知识和visio软件的基本用法，并进一步熟练掌握绘制用例框图基本步骤和方法。