信息系统分析与设计第四章
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 迭代式：便于分工，便于纠错，频繁的沟 通和联系致使既懂沟通，又懂系统分析的 人员紧缺。
• 阶段交付式：折中策略，由于上述人员紧 缺，就
• 将需求调查和系统分析外包，导致了此种
• 值得注意的是要避免实际开发过程中的一 种“伪迭代式”开发模型。
• 两种最常见的伪迭代症状：
• ①整个开发过程经历了若干次系统分析迭 代，若干次系统设计迭代，……，。
• B/S架构必须借助于web浏览器，把信息系 统设置在服务其上打开，客户端可以在浏 览器中输入特定网址，来访问信息系统。 借助一些特定的语言，比如Asp, Jsp等等。
• 显示：在用户界面上画出按钮图形。 • 事件的触发：生成按钮点击事件。
• 事件的响应：响应按钮点击事件并且做出 某种操作。
• 业务处理：进行实际的计算。
• 4、分层的优缺点
• ①易维护（当需求发生变化时，只做较小 的修改甚至是不修改，就能适应）
• ②可扩展性（增加新的功能，层数越少调 整越大）
• ③可重用性（系统中一个模块的重用性） • ⑤高安全性（层间设立安全机制） • ④可伸缩性（实际是建立和维持的关系）
数据池原理
• 建立一个数据库连接是一件非常耗时（消耗时间）耗力（ 消耗资源）的事情。之所以会这样，是因为连接到数据库 服务器需要经历几个漫长的过程:建立物理通道（例如套接 字或命名管道），与服务器进行初次握手，分析连接字符 串信息，由服务器对连接进行身份验证，运行检查以便在 当前事务中登记等等。
• 第一步：换名。 • 第二步：对类中的方法进行处理。这一步
远比第一步复杂得多，包括以下内容：
• ①去除不可实现的方法。 • ②增加功能实现必须的方法。 • ③改变方法作用域。 • ④为方法增加参数。 • ⑤改名。
• ①去除不可实现的方法。 • ②增加功能实现必须的方法。 • ③改变方法作用域。 • ④为方法增加参数。 • ⑤改名。
26
物理架构
• 软件元件是怎样放到硬件上的 • 下图是一个蓝电变电站信息管理系统解决方案中，就使用了C/S与B/S
混合结构的方式，其物理构架如下。
27
物理架构
28
4.2.2 系统架构的选择
• 双层架构的典型代表是C/S架构 • 三层架构的典型代表是B/S架构 • 基于B/S架构的信息系统开发中最常采用的
4.4.1 系统实体对象设计
• 实体对象设计的基本思路是在关系数据库 表字段
• 和实体对象属性之间建立映射关系。
• 关于数据冗余： • 冗余的好处的是可以实现一定程度的备份
，缺点
4.4.1 系统实体对象设计
• 一个实体对象可以对应一个数据库表，也 可以对应数据库表的一部分，还可以是几 个数据库表连接查询后返回的数据集合， 即实体对象应该是整个数据模型的某个子 集。
4.2 系统架构设计
• 4.2.1 系统架构简介 • 1、系统架构的概念 • 系统架构一般特指系统的软件架构（
Software Architecture），也被称作软件体 系结构，是有关软件整体结构与组件的抽 象描述，用于指导大型软件系统各个方面 的设计。
• 但是实际是一种比较形象的描述系统组成 的直观
4.1.3 功能设计的评价标准
• 总体的原则是出了问题不要滞留，尽早解 决。
• 1、正确性（原分析阶段的业务逻辑是否可 以正确执行）
• 2、完整性（结构完整和组成部分） • 3、可靠性（可靠的系统设计工具） • 4、类设计的合理性 • 5、接口定义严谨（能私有的不要公有） • 6、图表文档完备
4.1.4 系统设计的步骤及工作产品
• 具体参见（p117,1-4)
4.4.1 系统实体对象设计
• 实体类的合并，大类可以包含小类，但是 如果两
• 个类逻辑比较远可以不合并，制造必要的 冗余。
• 某些实体类可能是在流程对象和交互对象 设计中
• 发现的，这时需要检查其是否能映射回数
4.4.2 系统流程对象设计
• 系统流程指的是系统的业务流程，系统流 程设计是对系统分析阶段成果的进一步完 善和补充，也是按照整个系统架构设计思 路，从物理实现的角度对系统设计进行新 的分解和拓展。系统流程对象设计按照以 下两个步骤进行：
4.3 系统I/O设计
• 系统I/O设计包括两方面内容：一是与用户 交互与界面设计，二是业务数据的存储设 计，后者在面向对象开发中集中体现为对 象的持久化问题。
• C/S架构的界面设计比较简单，比如使用 Visual Studio 拖拽和可视化控件结合少量代 码实现。将数据库和数据库管理系统置于 服务器，在局域网客户端安装应用程序即 可。
• P99 4.1.2标题下的一段 • 1、类的物理结构，类间联系（核心是上一
章的那 • 个模型？） • 2、数据库的物理设计、输入输出设计 • 3、方案评价
4关于系统设计员
• 具备计算机知识和软件开发经营能力，又 懂系统分析和系统设计知识。
• 系统分析员在系统设计中不承担主要任务 ，但是负责对设计结果的评审和修正。
• ①过度分层将导致系统运行效率下降（用 空间换时间）
• ②分层导致系统设计愈发复杂 • ③运行调试困难 • ④不适合小系统
逻辑架构
• 软件系统中元件之间的关系，比如用户界面，数据库，外部系统接 口，商业逻辑元件等等。
24
逻辑架构
25
逻辑架构
问题，本书的会员卡管理系统，如果设计逻辑模 型应该是怎样的？
举例分析
• P112 图4-12——会员开管理功能页面 • P122 调整之后发生的变动
• 流程减少和代码重用（P121第三段） • 消息参数
4.4.3 系统的交互设计
• 以卡类型管理中的查询功能的实现为例， 其完整的交互过程如图所示
• 系统交互设计时应该首先作“加法”，即 根据系统功能不断向设计中添加新类；当 相关的一组功能做完后，再对设计图作“ 减法”。将功能一样但命名不同的类删除 ，将功能近似的类利用重构技术加以合并 ，将密切相关的类组织在一起，减少类的 数量，提升类的相关关系和继承层次。
• 连接池就是这样一个容器：它存放了一定数量的与数据库 服务器的物理连接。因此，当我们需要连接数据库服务器 的时候，只需去池（容器）中取出一条空闲的连接，而不 是新建一条连接。这样的话，我们就可以大大减少连接数 据库的开销，从而提高了应用程序的性能。
• 软件分层并非百利而无一害，分层的缺点 主要包括
是MVC（Model-View- Controller，模型—视 图—控制器）架构模式 • 模型：数据提取和处理（并不是数据持久 层）
• 试图：以恰当的形式呈现数据，与用户交 互。
用户请求 视图选择
视图
控制器
数据状态更新
数据状态查询 变更通知
模型
书的107页（1）-（5）。 不要与三层构架混淆，不适合小型系统
架构设计
表述层
应用程序
或
业务逻辑
数据库
数据库
持久化设计
业务逻辑1
业务逻辑2
业务逻辑n
实体对象
ORM接口（API） ORM实现
对象－关 系映射文
件
（XML）
关系数据库
功能设计
: Staff2
: login.jsp
登录
doBody( )
登录验 参数： 用户名、口令
: Login
: Dispatcher
: PGCardSpecManagement.jsp
表述层
表述层
业务逻辑
业务逻辑
数据库
（a）
硬件分层 系统逻辑分层
数据库
（b）
• 3、软件分层的特征
• ①层与层之间应该存在且只能够存在自上 而下的依赖关系
• ②每层只对上层公开接口，把实现细节封 装起来，不为外界所知，即所谓的“透明 ”
• ③同层组成部分之间应该存在内在的逻辑 联系，不要把与本层业务关系较弱的程序 包含进来
1234
子系统1 低层系统设计
子系统2 低层系统设计
系统测试 系统实施
系统测试 系统实施
低层系统设计
低层系统设计
系统测试 系统实施
系统测试 系统实施
子系统3
子系统4
瀑布式和迭代式的结合
按照瀑布式做系统分析和高层系统设计
按迭代式完成子系统设计，实施和测试。
三种方式的比较
• 瀑布式：过于理想化，越来越少
:
: CardSpec
PGCardSpecManagement
:
PGCardSpecManagement_query.jsp
doCommand(String)
参数：命令类型 选择操作类型
open URL
通过request 或者session 传递命令和 参数
doBody( )
显示操作界面
: CardSpecBean
系统测试 系统实施
系统测试 系统实施
子系统3 子系统4
系统分析 系统设计
系统分析 系统设计
系统
系统测试 系统实施
系统测试 系统实施
子系统3
子系统4
首先，进行子系统划分 各子系统过程，力求每一个系统直接进入运行状态
最后，完成集成。
Βιβλιοθήκη Baidu
• 3、阶段交付式开发
系统分析
高层系统设计
子子子子 系系系系 统统统统
Servlet (/index) html_footer.jsp
PGCardSpecMa nagement_edit.js
p PGCardSpecMa nagement_delete
.js PGCardSpecMa nagement_save.j
sp
PPGGCCaarrddSSppeeccMMaannaage gmemenetn_tq_udeisrpy..jjsspp
第4章 系统设计
第四 章 系统设计
• 理解系统设计的基本概念 • 掌握架构设计 • 掌握持久化设计 • 掌握功能设计 • 掌握界面设计
2
系统设计做什么
• 面向对象的技术特征 • 该环节为系统实现设计出图纸，关注系统
实现的 • 所有细节 • 细逻辑模，要更多地结合物理实现
4.1系统设计概述
• 4.1.1 面向对象的系统设计过程 • 信息系统开发过程主要包括瀑布式（
4.1.2 功能设计的基本任务
• 系统功能设计需要考虑以下几个方面的问 题
• 1、寻找到合适的对象（P100第二段） • 2、决定对象的粒度（P100小标题） • 同样一个系统，两个设计师给出两种设计
。第一 • 个设计有5个类，第二个25个类。这样平均
起来每 • 个类所含有的代码行数就有很大的区别，
4.3.2 对象的持久化(❤P113❤)
• 对象持久化考虑如何将运行系统中的业务 数据永
• 久保存。
• 业务对象在内在中无法永久保存，要么导 出数据
• 文件，要么存入数据库，否则就会丢失。
• 并非所有对象都需要保存，保存什么主要
4.4 系统功能设计
• 系统功能设计包括系统实体对象设计、系 统流程对象设计和系统交互设计三部分。
• 图。
• 系统架构的变迁
程序 +
数据
单层架构
应用程序 数据库
双层架构
应用程序和数据的分离 表述层和业务逻辑的分离
表述层 业务逻辑
数据库 三层架构
• P103 • 表述层：提供人机交互界面（GUI）
• 业务逻辑层：实现各种业务逻辑（比如身份 验证）
• 数据库：提供数据
• 2、物理分层和逻辑分层P(104)
Waterfall）、迭代式（Iterative）和综合了 前两者特点的阶段交付（Staged Delivery） 式三种开发模型。
• 1、瀑布式开发
系统分析
系统设计
系统实施
系统测试
自上而下，环环相扣 避免逆向过程
• 2、迭代式开发
子系统1 系统分析 系统设计
子系统2 系统分析 系统设计
子系统1 子系统2
4.2.3 系统架构的配置
• 系统架构的配置应在系统总体架构确定后 应尽快加以明确。系统架构的配置决定了 后续开发过程中软硬件资源的分布和配比 ，也可能根据给定的软硬件资源确定具体 采用哪种架构。
• B/S架构的配置(一般至少两台服务器，数据 服务器和web服务器）
• C/S架构的配置（至少一台数据服务器）
执行操作（输入关键字）
query(CardSpecKey)
显示结果
创建 取得Bean
生成
界面设计
PGhCtmarld_hSepaedceMr.jasnpage smesesinotn.j.sjspp
PGCardSpecMana gement_Menu.jsp
PGCardSpecMana gement
• ②经过多次迭代，得到了接近完工的产品 ，只差最后的测试。
• 两种伪迭代式的开发模型
系统分析
系统设计
系统实施
子系统1 系统分析 系统设计
（a） 子系统2
系统分析 系统设计
系统实施
系统实施
系统分析 系统设计
系统分析 系统设计
系统实施 子系统3
系统实施
子系统4 （b）
系统测试 系统测试
4.1.2 功能设计的基本任务
• 阶段交付式：折中策略，由于上述人员紧 缺，就
• 将需求调查和系统分析外包，导致了此种
• 值得注意的是要避免实际开发过程中的一 种“伪迭代式”开发模型。
• 两种最常见的伪迭代症状：
• ①整个开发过程经历了若干次系统分析迭 代，若干次系统设计迭代，……，。
• B/S架构必须借助于web浏览器，把信息系 统设置在服务其上打开，客户端可以在浏 览器中输入特定网址，来访问信息系统。 借助一些特定的语言，比如Asp, Jsp等等。
• 显示：在用户界面上画出按钮图形。 • 事件的触发：生成按钮点击事件。
• 事件的响应：响应按钮点击事件并且做出 某种操作。
• 业务处理：进行实际的计算。
• 4、分层的优缺点
• ①易维护（当需求发生变化时，只做较小 的修改甚至是不修改，就能适应）
• ②可扩展性（增加新的功能，层数越少调 整越大）
• ③可重用性（系统中一个模块的重用性） • ⑤高安全性（层间设立安全机制） • ④可伸缩性（实际是建立和维持的关系）
数据池原理
• 建立一个数据库连接是一件非常耗时（消耗时间）耗力（ 消耗资源）的事情。之所以会这样，是因为连接到数据库 服务器需要经历几个漫长的过程:建立物理通道（例如套接 字或命名管道），与服务器进行初次握手，分析连接字符 串信息，由服务器对连接进行身份验证，运行检查以便在 当前事务中登记等等。
• 第一步：换名。 • 第二步：对类中的方法进行处理。这一步
远比第一步复杂得多，包括以下内容：
• ①去除不可实现的方法。 • ②增加功能实现必须的方法。 • ③改变方法作用域。 • ④为方法增加参数。 • ⑤改名。
• ①去除不可实现的方法。 • ②增加功能实现必须的方法。 • ③改变方法作用域。 • ④为方法增加参数。 • ⑤改名。
26
物理架构
• 软件元件是怎样放到硬件上的 • 下图是一个蓝电变电站信息管理系统解决方案中，就使用了C/S与B/S
混合结构的方式，其物理构架如下。
27
物理架构
28
4.2.2 系统架构的选择
• 双层架构的典型代表是C/S架构 • 三层架构的典型代表是B/S架构 • 基于B/S架构的信息系统开发中最常采用的
4.4.1 系统实体对象设计
• 实体对象设计的基本思路是在关系数据库 表字段
• 和实体对象属性之间建立映射关系。
• 关于数据冗余： • 冗余的好处的是可以实现一定程度的备份
，缺点
4.4.1 系统实体对象设计
• 一个实体对象可以对应一个数据库表，也 可以对应数据库表的一部分，还可以是几 个数据库表连接查询后返回的数据集合， 即实体对象应该是整个数据模型的某个子 集。
4.2 系统架构设计
• 4.2.1 系统架构简介 • 1、系统架构的概念 • 系统架构一般特指系统的软件架构（
Software Architecture），也被称作软件体 系结构，是有关软件整体结构与组件的抽 象描述，用于指导大型软件系统各个方面 的设计。
• 但是实际是一种比较形象的描述系统组成 的直观
4.1.3 功能设计的评价标准
• 总体的原则是出了问题不要滞留，尽早解 决。
• 1、正确性（原分析阶段的业务逻辑是否可 以正确执行）
• 2、完整性（结构完整和组成部分） • 3、可靠性（可靠的系统设计工具） • 4、类设计的合理性 • 5、接口定义严谨（能私有的不要公有） • 6、图表文档完备
4.1.4 系统设计的步骤及工作产品
• 具体参见（p117,1-4)
4.4.1 系统实体对象设计
• 实体类的合并，大类可以包含小类，但是 如果两
• 个类逻辑比较远可以不合并，制造必要的 冗余。
• 某些实体类可能是在流程对象和交互对象 设计中
• 发现的，这时需要检查其是否能映射回数
4.4.2 系统流程对象设计
• 系统流程指的是系统的业务流程，系统流 程设计是对系统分析阶段成果的进一步完 善和补充，也是按照整个系统架构设计思 路，从物理实现的角度对系统设计进行新 的分解和拓展。系统流程对象设计按照以 下两个步骤进行：
4.3 系统I/O设计
• 系统I/O设计包括两方面内容：一是与用户 交互与界面设计，二是业务数据的存储设 计，后者在面向对象开发中集中体现为对 象的持久化问题。
• C/S架构的界面设计比较简单，比如使用 Visual Studio 拖拽和可视化控件结合少量代 码实现。将数据库和数据库管理系统置于 服务器，在局域网客户端安装应用程序即 可。
• P99 4.1.2标题下的一段 • 1、类的物理结构，类间联系（核心是上一
章的那 • 个模型？） • 2、数据库的物理设计、输入输出设计 • 3、方案评价
4关于系统设计员
• 具备计算机知识和软件开发经营能力，又 懂系统分析和系统设计知识。
• 系统分析员在系统设计中不承担主要任务 ，但是负责对设计结果的评审和修正。
• ①过度分层将导致系统运行效率下降（用 空间换时间）
• ②分层导致系统设计愈发复杂 • ③运行调试困难 • ④不适合小系统
逻辑架构
• 软件系统中元件之间的关系，比如用户界面，数据库，外部系统接 口，商业逻辑元件等等。
24
逻辑架构
25
逻辑架构
问题，本书的会员卡管理系统，如果设计逻辑模 型应该是怎样的？
举例分析
• P112 图4-12——会员开管理功能页面 • P122 调整之后发生的变动
• 流程减少和代码重用（P121第三段） • 消息参数
4.4.3 系统的交互设计
• 以卡类型管理中的查询功能的实现为例， 其完整的交互过程如图所示
• 系统交互设计时应该首先作“加法”，即 根据系统功能不断向设计中添加新类；当 相关的一组功能做完后，再对设计图作“ 减法”。将功能一样但命名不同的类删除 ，将功能近似的类利用重构技术加以合并 ，将密切相关的类组织在一起，减少类的 数量，提升类的相关关系和继承层次。
• 连接池就是这样一个容器：它存放了一定数量的与数据库 服务器的物理连接。因此，当我们需要连接数据库服务器 的时候，只需去池（容器）中取出一条空闲的连接，而不 是新建一条连接。这样的话，我们就可以大大减少连接数 据库的开销，从而提高了应用程序的性能。
• 软件分层并非百利而无一害，分层的缺点 主要包括
是MVC（Model-View- Controller，模型—视 图—控制器）架构模式 • 模型：数据提取和处理（并不是数据持久 层）
• 试图：以恰当的形式呈现数据，与用户交 互。
用户请求 视图选择
视图
控制器
数据状态更新
数据状态查询 变更通知
模型
书的107页（1）-（5）。 不要与三层构架混淆，不适合小型系统
架构设计
表述层
应用程序
或
业务逻辑
数据库
数据库
持久化设计
业务逻辑1
业务逻辑2
业务逻辑n
实体对象
ORM接口（API） ORM实现
对象－关 系映射文
件
（XML）
关系数据库
功能设计
: Staff2
: login.jsp
登录
doBody( )
登录验 参数： 用户名、口令
: Login
: Dispatcher
: PGCardSpecManagement.jsp
表述层
表述层
业务逻辑
业务逻辑
数据库
（a）
硬件分层 系统逻辑分层
数据库
（b）
• 3、软件分层的特征
• ①层与层之间应该存在且只能够存在自上 而下的依赖关系
• ②每层只对上层公开接口，把实现细节封 装起来，不为外界所知，即所谓的“透明 ”
• ③同层组成部分之间应该存在内在的逻辑 联系，不要把与本层业务关系较弱的程序 包含进来
1234
子系统1 低层系统设计
子系统2 低层系统设计
系统测试 系统实施
系统测试 系统实施
低层系统设计
低层系统设计
系统测试 系统实施
系统测试 系统实施
子系统3
子系统4
瀑布式和迭代式的结合
按照瀑布式做系统分析和高层系统设计
按迭代式完成子系统设计，实施和测试。
三种方式的比较
• 瀑布式：过于理想化，越来越少
:
: CardSpec
PGCardSpecManagement
:
PGCardSpecManagement_query.jsp
doCommand(String)
参数：命令类型 选择操作类型
open URL
通过request 或者session 传递命令和 参数
doBody( )
显示操作界面
: CardSpecBean
系统测试 系统实施
系统测试 系统实施
子系统3 子系统4
系统分析 系统设计
系统分析 系统设计
系统
系统测试 系统实施
系统测试 系统实施
子系统3
子系统4
首先，进行子系统划分 各子系统过程，力求每一个系统直接进入运行状态
最后，完成集成。
Βιβλιοθήκη Baidu
• 3、阶段交付式开发
系统分析
高层系统设计
子子子子 系系系系 统统统统
Servlet (/index) html_footer.jsp
PGCardSpecMa nagement_edit.js
p PGCardSpecMa nagement_delete
.js PGCardSpecMa nagement_save.j
sp
PPGGCCaarrddSSppeeccMMaannaage gmemenetn_tq_udeisrpy..jjsspp
第4章 系统设计
第四 章 系统设计
• 理解系统设计的基本概念 • 掌握架构设计 • 掌握持久化设计 • 掌握功能设计 • 掌握界面设计
2
系统设计做什么
• 面向对象的技术特征 • 该环节为系统实现设计出图纸，关注系统
实现的 • 所有细节 • 细逻辑模，要更多地结合物理实现
4.1系统设计概述
• 4.1.1 面向对象的系统设计过程 • 信息系统开发过程主要包括瀑布式（
4.1.2 功能设计的基本任务
• 系统功能设计需要考虑以下几个方面的问 题
• 1、寻找到合适的对象（P100第二段） • 2、决定对象的粒度（P100小标题） • 同样一个系统，两个设计师给出两种设计
。第一 • 个设计有5个类，第二个25个类。这样平均
起来每 • 个类所含有的代码行数就有很大的区别，
4.3.2 对象的持久化(❤P113❤)
• 对象持久化考虑如何将运行系统中的业务 数据永
• 久保存。
• 业务对象在内在中无法永久保存，要么导 出数据
• 文件，要么存入数据库，否则就会丢失。
• 并非所有对象都需要保存，保存什么主要
4.4 系统功能设计
• 系统功能设计包括系统实体对象设计、系 统流程对象设计和系统交互设计三部分。
• 图。
• 系统架构的变迁
程序 +
数据
单层架构
应用程序 数据库
双层架构
应用程序和数据的分离 表述层和业务逻辑的分离
表述层 业务逻辑
数据库 三层架构
• P103 • 表述层：提供人机交互界面（GUI）
• 业务逻辑层：实现各种业务逻辑（比如身份 验证）
• 数据库：提供数据
• 2、物理分层和逻辑分层P(104)
Waterfall）、迭代式（Iterative）和综合了 前两者特点的阶段交付（Staged Delivery） 式三种开发模型。
• 1、瀑布式开发
系统分析
系统设计
系统实施
系统测试
自上而下，环环相扣 避免逆向过程
• 2、迭代式开发
子系统1 系统分析 系统设计
子系统2 系统分析 系统设计
子系统1 子系统2
4.2.3 系统架构的配置
• 系统架构的配置应在系统总体架构确定后 应尽快加以明确。系统架构的配置决定了 后续开发过程中软硬件资源的分布和配比 ，也可能根据给定的软硬件资源确定具体 采用哪种架构。
• B/S架构的配置(一般至少两台服务器，数据 服务器和web服务器）
• C/S架构的配置（至少一台数据服务器）
执行操作（输入关键字）
query(CardSpecKey)
显示结果
创建 取得Bean
生成
界面设计
PGhCtmarld_hSepaedceMr.jasnpage smesesinotn.j.sjspp
PGCardSpecMana gement_Menu.jsp
PGCardSpecMana gement
• ②经过多次迭代，得到了接近完工的产品 ，只差最后的测试。
• 两种伪迭代式的开发模型
系统分析
系统设计
系统实施
子系统1 系统分析 系统设计
（a） 子系统2
系统分析 系统设计
系统实施
系统实施
系统分析 系统设计
系统分析 系统设计
系统实施 子系统3
系统实施
子系统4 （b）
系统测试 系统测试
4.1.2 功能设计的基本任务