C5 UML基础-1-用例图

null第5章 UML基础第5章 UML基础第五章 UML基础(上）第五章 UML基础(上）5.1 面向对象的主要概念 5.2 UML基础 5.3 用例图 ……5.1 面向对象的主要概念5.1 面向对象的主要概念面向对象技术的基本观点: 客观世界由对象组成，任何客观实体都是对象，复杂对象可以由简单对象组成。 具有相同数据和操作的对象可归纳成类，对象是类的一个实例。 类可以派生出子类，子类除了继承父类的全部特性外还可以有自己的特性。 对象之间的联系通过消息传递来维系。软件发展的复杂性软件发展的复杂性随着信息技术的发展，软件复杂性的增长，使软件开发越来越困难软件可能是人类制造出来的最复杂的实体面向对象的分析和 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 (OOA&D)面向对象的分析和设计 (OOA&D)面向对象的方法按照人类的自然思维的方式，面对客观世界建立软件模型。 充分体现了对复杂系统进行分解、抽象、模块化等思想 OOA依照用户所理解的真实世界中的对象和概念，发现和分析对象的内部构成和外部关系，建立准确而简洁的软件系统的对象模型。 OOD 是根据已建立的系统对象模型，运用面向对象技术，进行软件设计。 面向对象的核心元素面向对象的核心元素对象 封装 消息 类 继承 多态性 结构与连接 1. 对象1. 对象客观世界里的任何实体都可以被称为对象。 对象可以是具体的、有形的物，也可以是无形的事物或概念。 对象是问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 域或实现域中某些事物的一个抽象。 对象是一个封装数据属性和操作行为的实体。 系统中的对象在软件生命周期的各个阶段可能有不同的表示形式。一个对象的实例图解一个对象的实例图解2. 封装2. 封装封装是面向对象方法的一个重要原则。 封装有两个含义： 结合性 信息隐蔽性2. 封装2. 封装封装实际上是一种信息隐藏技术，抽象性通过封装得以实现。 封装就是指将对象的方法程序和属性代码包装在一起。封装将操作对象的内部复杂性与应用程序的其它部分隔离开来。 例如，我们将电话的零部件和线路封装在电话的外壳里，这样使用户看不到电话内部线路的复杂性，只专心拨号、讲话、听音，从而也产生用户对电话具有拨号、讲话、听音功能这种抽象化的认识。3. 消息3. 消息消息是向对象发出的服务请求。 一个消息包含消息名、接受对象的标志、服务标志、输入信息、回答信息等。 消息传递机制。“开机”消息4. 类4. 类类是一组具有相同数据结构和相同操作的对象的集合。 类是对象的抽象。 客观世界实际存在的都是对象，而不是类 。 类和对象的关系。 5. 继承5. 继承继承性是面向对象程序设计语言不同于其他语言的最主要特点。继承是指子类可以自动拥有父类的全部属性与操作的机制。 例如，由基本类型的电话（拨号、讲话、听音功能），可以派生出电话传真机、移动电话、公用投币电话等，这些电话都继承了电话基本类型的拨号、讲话、听音功能，又添加了各自的独特功能。 由于有了继承性，当我们把基本类型的电话由拨号改为按键，其它类型的电话都可以改为按键，继承性使我们不必研究每种电话如何实现按键。5. 继承5. 继承继承的描述：5. 继承5. 继承继承性又分为单重继承和多重继承两类。 5. 继承5. 继承继承性又分为单重继承和多重继承两类。 6. 多态性6. 多态性定义：同一操作作用于不同的对象，可以有不同的解释，产生不同的执行结果。 多态性的实现方式： 通过接口实现多态性 通过继承实现多态性 通过抽象类实现多态性[例]打开： 门 窗 礼物5.2 UML基础5.2 UML基础为什么要建模模型是现实的简化模型是现实的简化模型提供了系统的设计图。模型可以包含详细的规划，也可以包含概括性的规划，这种规划高度概括了正在考虑的系统。好的模型包括那些具有高度抽象性的元素。 模型有助于按原样或根据需要使系统可视化 通过模型可以详细说明系统的结构或行为 模型可以提供一个指导我们构建系统的模板 模型可以 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 已经做出的决策面向对象的建模面向对象的建模选择以面向对象的方式来分析问题将衍生出许多结果： 一个良好的面向对象的体系应具有什么结构？ 项目应该创建哪些部件？ 应该由谁来创建这些部件？ 应该如何度量它们？对面向对象的系统进行可视化、规格说明、构建和文档化正是统一建模语言（UML）的目的。 UML的发展过程UML的发展过程P137OMG: Object Management Group，美国工业 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 化组织UML 简介UML 简介统一建模语言UML(Unified Modeling Language)是一种绘制软件蓝图的标准语言。 是一种通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。 用于对系统的理解、设计、浏览、配置、维护和信息控制。 从企业信息系统到基于Web的分布式应用，甚至严格的实时嵌入式系统都适合于用UML来建模。 它是一种富有表达力的语言，可以描述开发所需要的各种视图，然后以此为基础开发系统。 UML为模型可视化提供表示法UML为模型可视化提供表示法说明用户与系统的交互的用例图 说明逻辑结构的类图 说明对象和链接的对象图 说明行为的状态图 说明软件的物理结构的构件图 显示软件与硬件配置之间的映射关系的部署图 说明行为的交互图（即协作图和时序图） 说明用例中事件流的活动图UML的组成UML的组成视图(View) - 意味着“观察”或“检查” 图表(Diagram) - 是特定视图的一部分，图表绘制完后，就会被指定给视图 建模元素 - 由帮助准备图表和视图的符号组成 关系 - 提供了对象之间通信的途径模型元素模型元素Rational Rose简介 Rational Rose简介 5.3 用例图5.3 用例图5.3.1 概述 5.3.2 用例图的应用 5.3.3 实例—图书馆管理系统的用例图 5.3.4 进一步了解用例图5.3.1 概述5.3.1 概述用例图用于描述系统的功能集。它是从系统外部，以用户角度为出发点，对系统进行抽象表示。 用例图所描述的系统功能依靠外部用户或另一个系统激活，为其提供服务，实现与其之间的交互。 外部用户或另一个系统---参与者，服务---用例； 用例图显示谁将是相关的用户、用户希望系统提供什么服务或是用户需要为系统提供的服务。 用例图最常用来描述系统以及子系统。 null用例图包含3个部分： ①参与者（Actor） ②用例（Use Case） ③关系： 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization）一、参与者一、参与者系统外部的一个实体。 参与用例的执行过程。 通过向系统输入或请求系统输入某些事件来触发系统的执行。 由参与用例时所担当的角色来表示。 每个参与者可以参与一个或多个用例。 一、参与者一、参与者参与者的种类： 系统用户 与所建造的系统交互的其他系统 一些可以运行的进程参与者之间的关系参与者之间的关系在用例图中，使用泛化关系来描述多个参与者之间的公共行为参与者间的泛化关系示例： 会员(普通会员，VIP) 学生(中学生，小学生)二、用例二、用例定义： 对一组动作序列的描述，系统通过执行这一组动作序列为参与者产生一个可观察的结果 说明： 外部可见的系统功能单元。 在不揭示系统内部构造的前提下定义连贯的行为。 不是需求或功能的规格说明，但是也展示和体现其所描述的过程中的需求情况。 二、用例二、用例用例的名称： 简单名 路径名三、用例间的关系三、用例间的关系关系反应了参与者和用例之间、用例和用例之间以及参与者和参与者之间的相互作用 关联关系（association） 泛化关系（generalization） 包含关系（include） 扩展关系（extend）① 关联关系(association)① 关联关系(association)表示参与者与用例之间进行通信。 不同的参与者可以访问相同的用例。 关联关系表示一种通信路径，它存在于参与者和用例之间，提供用例和参与者之间的通信途径。建立通信之后，信息可以双向流动。 关系方向显示的不是信息的流动方向，而是谁启动信息。 ① 关联关系(association)① 关联关系(association)表示 工具箱中：一个直角箭头 模型图中：一条直线 或者一条带箭头的直线 关联的命名 一个动词或者一个动词短语，用于指明关系的类型或者目的。 关联关系表示通信途径 ① 关联关系(association)① 关联关系(association)在用例图中，通常存在两种类型的关联： 单向关联 双向关联 Actor1 与 UseCase1 Actor2 与 UseCase1② 泛化关系(generalization)② 泛化关系(generalization)表示一般与特殊的关系 定义： 在一个更一般的模型要素和另一个较具体的模型要素之间存在的一种关系，通常用于表示类（包括用例、参与者等）之间的继承关系 表示方法： 工具箱中： 模型图中：一条带空心三角形箭头的实线（箭头方向从具体用例指向一般用例）② 泛化关系(generalization)② 泛化关系(generalization)用例之间的泛化关系参与者之间的泛化关系补充：依赖关系(dependency)补充：依赖关系(dependency)定义 存在于两个模型要素之间的一种关系：其中一个模型要素的改变将影响另一个模型要素 有扩展关系、包含关系 表示方法 工具箱和模型图中均表示为一个带箭头的虚线 画图时，拖动鼠标从客户到提供者画出关联关系 ③ 扩展关系(extend)③ 扩展关系(extend)扩展用例被定义为基础用例的增量扩展。 基础用例提供扩展点以添加新的行为。 扩展用例提供插入片段以插入到基础用例的扩展点上。 ③ 扩展关系(extend)③ 扩展关系(extend)关系的扩展： 扩展关系可以放置在所有的关系上 扩展关系用带箭头的虚线表示，沿线上加一个用双尖括号括起来的“extend” ③ 扩展关系(extend)③ 扩展关系(extend)常见的几种扩展关系： a.两个用例相似但不完全相同时 b.要对多个额外情况逐一建模时，可使用扩展关系，用一个独立的用例替代每个额外的情况 c.如果用例涵盖了所有的情况变化，则该用例将会变得十分复杂，应该考虑使用扩展关系 ④ 包含关系(include)④ 包含关系(include)包含关系：在一个用例中重用(reuse)另一个用例中的步骤 是一种构造型关系，它将一个基用例连接到一个包含用例 包含关系用带箭头的虚线表示，沿线上加一个用双尖括号括起来的“include”④ 包含关系(include)④ 包含关系(include)使用包含关系的三种情况： a.如果有多个用例，并且这些用例包含大量类似的行为，应该考虑将这些类似的行为通过包含关系包含到用例中 b.对多个互相独立的用例建模时做了重复的工作，可以通过包含关系包含这些重复的工作 c.如果某个行为可能会引入冗余，或者，当行为发生变化时可能导致不一致性，这时，应该对这种行为进行孤立建模并将它包含到用例中 nulla.多个用例中有类似行为b.多个用例中有重复行为c.用例中有特殊行为包含与扩展的区别/联系包含与扩展的区别/联系包含关系：当可以从2个或2个以上的原始用例中提取公共行为，或者发现能够使用一个构件来实现某一个用例的部分功能时，应该使用包含关系来表示它们。 扩展关系：如果一个用例明显地混合了2种或2种以上的不同场景，即根据情况可能发生多种事情，可以断定，将这个用例分为一个主用例和一个或多个辅用例描述可能更加清晰。null思考题1思考题1在一个“订单输入子系统”中，创建新订单和更新订单都需要核查用户帐号是否正确。那么，用例“创建新订单”、“更新订单”与用例“核查客户帐号”之间是______关系？ A. 包含（include）　 　　　 B. 扩展（extend） C. 泛化（generalization）　 D. 关联（association）用例之间有包含、扩展、泛化等关系 创建新订单和更新订单都要先核查客户帐号这个用例,所以应该是包含关系思考题2思考题2在“某图书馆管理系统”用例模型中，所有用户使用系统之前必须通过“身份验证”，“身份验证”可以有 “密码验证”和“智能卡验证”两种方式，则“身份验证”与“密码验证”和“智能卡验证”之间是 ______关系。 A. 关联　　　　　B. 包含　　　　　 C. 扩展　　　　　D. 泛化 身份验证这一用例可以分成密码验证和智能卡验证二个辅用例,所以应该是泛化关系四、用例与事件流四、用例与事件流事件流 事件流是用例完成需求行为的事件描述。 目的是建立用例中逻辑流程的文档，详细描述系统用户的工作和系统本身的工作 包括正常状态下系统完成需求行为的事件 也包括在其他状态下不能完成需求行为的事件四、用例与事件流四、用例与事件流事件流通常包括： 1.简要说明 2.前提条件 3.事件流(主事件流、其他事件流、错误流) 4.后置条件5.3.2 用例图的应用5.3.2 用例图的应用用例图的主要作用是描述参与者和用例之间的关系 简单的系统中只需要有一个用例图就可以把所有的关系都描述清楚，复杂的系统中可以有多个用例图用例图建模技术用例图建模技术对语境建模 识别系统外部的参与者。 将类似的参与者组织成泛化的结构层次。 在需要加深理解的地方，为每个参与者提供一个构造型。 将参与者放入到用例图中，并说明参与者与用例之间的通信路径。 对需求建模用例图建模技术用例图建模技术对语境建模 对需求建模 识别系统的外部参与者来建立系统的语境。 考虑每一个参与者期望的行为或需要系统提供的行为。 把这些公共的行为命名为用例。 确定提供者用例和扩展用例。 对这些用例、参与者和它们之间的关系建模。 用注释修饰用例。 用例图示例用例图示例用例的发起者在用例图的左侧，接受者在用例图的右侧。 用例分析的一个好处是它能够展现出系统和外部世界之间的边界。 参与者是典型的系统外部实体，而用例是典型的属于系统内部。 系统的边界用一个矩形来代表，里面写上系统的名字。系统的用例装入矩形之内。用例图示例用例图示例要强调某一个参与者和多个用例的关系 可以以该参与者为中心，用一个用例图表述出该参与者和多个用例之间的关系。 强调的是该参与者会使用系统所提供的哪些服务。用例图示例用例图示例要强调某一个用例和多个参与者之间的关系 可以以该用例为中心，用一个用例图表述出该用例和多个参与者之间的关系。 强调的是该用例会涉及到哪些参与者，或者说该用例所表示的系统服务有哪些使用者。使用Rational Rose绘制用例图的步骤使用Rational Rose绘制用例图的步骤1.创建用例图 2.添加参与者与用例 3.添加参与者与用例之间的关系 4.添加用例之间的关系创建用例图创建用例图工具栏的定制工具栏的定制5.3.3 实例—图书馆管理系统的用例图 5.3.3 实例—图书馆管理系统的用例图 一、确定系统涉及的总体信息 二、确定系统的参与者 三、确定系统的用例 四、图书馆管理系统的用例图一、确定系统涉及的总体信息一、确定系统涉及的总体信息读者： 借书 还书 书籍预定系统管理员： 增加书目 删除或更新书目 增加书籍 减少书籍 增加读者帐户信息 删除或更新读者帐户信息 书籍信息查询 读者信息查询图书馆员： 书籍借出处理 书籍归还处理 预定信息处理二、确定系统的参与者二、确定系统的参与者首先分析系统所涉及的问题领域和系统运行的主要任务： 分析使用该系统主要功能部分的是哪些人。 谁将需要该系统的支持以完成其工作。 系统的管理者与维护者。图书馆管理系统的参与者： 读者（借阅者） 图书馆员 图书馆管理系统维护者 三、确定系统的用例三、确定系统的用例1.借阅者请求服务的用例 2.图书馆员处理借书、还书等的用例 3.系统管理员进行系统维护的用例 1.借阅者请求服务的用例1.借阅者请求服务的用例登录系统：在可联网的电脑上登录图书馆系统 查询自己的借阅信息：借阅历史，个人资料等 查找书籍信息：找感兴趣的书 预定书籍：发现感兴趣的书之后，申请预定 借阅书籍：去图书馆办理借阅手续 归还书籍：去图书馆办理归还手续 可能有“罚款”的情况这样对吗？这样对吗？问题在哪里？问题在哪里？1.用例图不是活动图或流程图，不需要关心用例/业务间的先后顺序 2.在用例图中，关联关系只存于参与者和用例之间，不存在于用例和用例之间。分析：找出用例间的层次和关系分析：找出用例间的层次和关系找出平等和相对独立的主要业务： 登录不是一种业务，只是完成某些业务的一个步骤。实际处理过程是判断用户有没有登录，若未登录则给出提示或跳转到登录页面。 借书、还书、预定是相对独立的主要业务 罚款不是独立业务 检索信息可以算是相对独立的业务 找书可以算是相对独立的业务，也可理解为预定前的一个步骤。考虑到找过之后也可以不借不预定，暂定为相对独立的业务。找出平等和相对独立的主要业务找出平等和相对独立的主要业务分析：找出用例间的层次和关系分析：找出用例间的层次和关系找出依赖关系 登录是借阅者检索个人信息和预定时需要包括的步骤 借书、还书是由图书馆员办理手续，馆员需要先登录系统，但不需要借阅者登录系统 找书可以不需要登录，找到感兴趣的书以后，要预定时再登录系统就可以了 罚款不是独立业务，依赖于还书，是一个扩展情况借阅者请求服务的用例图借阅者请求服务的用例图2.图书馆员处理借/还书等的用例2.图书馆员处理借/还书等的用例处理书籍借阅：给借阅者办理借书手续时，应先查询借阅者的帐户信息，确定有权借书，才能办手续。 处理书籍归还：检查有没有需要处罚的情况。 处理/删除预定信息：取消已完成的或超期的预定。 图书馆员一上班就先登录到系统，才可以开始工作，直到下班才退出系统，所以每笔业务上不需要考察用户有没有登录这种问题了“借书”与相关用例的关系“借书”与相关用例的关系检查帐户：借书前须先检查借阅者的帐户信息。 取消预订： 办理借阅后，若是事先有预定，应取消该预定。是依赖关系。 超期没来借阅的预定，也可以主动取消，是独立业务问：是包含关系吗？2.图书馆员处理借/还书的用例图2.图书馆员处理借/还书的用例图与主业务相关的用例图与主业务相关的用例图3.系统管理员进行系统维护的用例3.系统管理员进行系统维护的用例查询借阅者信息 查询书籍信息 增加书目 删除或更新书目 增加书籍 删除书籍 添加借阅者帐户 删除或更新借阅者帐户3.系统管理员进行系统维护的用例图3.系统管理员进行系统维护的用例图5.3.4 进一步了解用例图5.3.4 进一步了解用例图一、用例的构成 二、用例的特征 三、用例的粒度和层次 四、系统的边界 五、一些误区一、用例的构成一、用例的构成用例：做饭 前置条件：要有米 后置条件：米变成了饭 场景1：用电饭煲做 场景2：用蒸笼做其它情况：如果是糙米，需要先淘米；如果是精米，则可略过淘米的步骤直接下锅。二、用例的特征二、用例的特征1.用例是相对独立的填写取款单不是取款人的目的，因此不是用例二、用例的特征二、用例的特征2.用例的执行结果对参与者来说是可观测的和有意义的 后台监控对参与者来说是不可观测的，应在补充规约中定义，而不是一个用户需求。 输入密码对参与者没有意义。那么，系统登录呢？二、用例的特征二、用例的特征3.事情必须由一个参与者发起。 不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。 ATM是没有吐钞的愿望的，因此不能驱动用例二、用例的特征二、用例的特征4.用例必然是以动宾短语形式出现的。 用例必须有一个动作和动作的受体。“喝”不能构成一个完整的事件，因此不能用来命名用例二、用例的特征二、用例的特征5.一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元、部署单元。 一旦决定了用例，软件开发工作的其他活动都以其为基础，围绕它进行。三、用例的粒度和层次三、用例的粒度和层次用例的粒度 例如，在ATM取钱的场景中，取钱、读卡、验证帐号、打印回执单等都是可能的用例。 取钱包括了另几个用例，粒度较大。 到底是一个大的用例合适还是分解成多个小用例合适呢？用例的粒度用例的粒度同一阶段同一层次，用例的粒度应一致 例如，在ATM取钱的场景中，取钱、读卡、验证帐号、打印回执单等都是可能的用例。 取钱包括了另几个用例，粒度较大用例的层次用例的层次用用例间的级别层次关系来组织 用例图可以划分为系统层（最高层）、子系统层（可以再细分）和对象类层（最低层）： 系统层(高层用例图)：描述系统提供的全部服务。 子系统层：描述子系统提供的服务，它的外部交互者可以是其他的子系统或高一层的参与者。 对象类层：描述对象类提供的功能片或操作，它的外部交互者可以是其他对象类或高一层活动者。四、系统的边界四、系统的边界边界是面向对象方法的一个重要概念 与封装的概念师出同源 任何对象都有一个边界，外界只能通过这个边界来认识对象，与对象打交道，而对象内部则是一个禁区 系统边界，即需求的集合，业务的范围边界四、系统的边界四、系统的边界在准备发现用例之前，先确定： 主角是位于系统边界外的 主角对系统有着明确的期望和明确的回报要求 主角的期望和回报要求在系统边界之内 [例] Pos系统的参与者是出纳员和顾客，对吗？不同系统边界的主要参与者和目标不同系统边界的主要参与者和目标不同系统边界的主要参与者和目标不同系统边界的主要参与者和目标五、一些误区五、一些误区1.用例和功能的误区 用例不是功能 是从参与者角度如何使用系统 描述事物的三种观点：null结构性观点 从结构上说，一个圆环，用在汽车上，可能是方向盘，用在自行车上，可以是轮子。 无法说明事物的作用。所以仅有结构性观点是不够的。 功能性观点 说明事物可利用的价值。 缺乏上下文环境，没有使用者，事物的可利用价值可能是无意义的。 使用者观点 说明事物对于使用者的意义，以及使用者如何使用它，得到什么样的利益。 不能够说明事物的本质结构。2.目标和步骤的误区2.目标和步骤的误区一个用例是参与者对目标系统的一个愿望，一个完整的事件 为了完成这个事件需要经由多个步骤，但这些步骤不能完整地反映参与者的目标，不能够作为用例 例如：假设邮局是一个目标系统，作为寄信人这样的参与者，对邮局有着寄信的愿望。2.目标和步骤的误区2.目标和步骤的误区若换一个描述方式，可不可以呢？ 试用文字描述有关的用例：寄信人到邮局付钱？ 但如果改变系统边界，对邮局收银员的业务来说，收钱是一个业务目标就是合理的了2.目标和步骤的误区2.目标和步骤的误区也可以理解为是用例粒度的错误 不同粒度、不同边界的用例，不应该出现在同一张图纸中 例如，在描述一栋建筑时，总是把高度、层数、单元数等合在一起介绍，而把下水道位置、插座数量等合在一起介绍。 如果这样介绍：此楼有10层，下水道在厨房东南角，预留了15个插座，共有5个单元……就显得比较混乱了案例：ATM取款机案例：ATM取款机需求描述： 客户代表说，我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可以让我选择是取钱还是存钱;为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也可以挂失；还有我希望可以交纳电话费、水费、电费等费用；为了安全起见，ATM上应当有警示小心骗子的提示条，还有摄像头；如果输入三次密码错误，卡片应当被自动吞没。案例：ATM取款机案例：ATM取款机哪些是有效用例？（参考） 支持跨行业务 插入卡片 输入密码 选择服务 取钱 存钱 交纳费用 挂失 警示骗子、摄像头 三次错误吞没卡片 × 是一个业务规则，限定业务的范围 × 是一个过程步骤，不是完整目标 × 是一个过程步骤，不是完整目标 × 是一个过程步骤，不是完整目标 √ 是一个有效的完整目标 √ 是一个有效的完整目标 √ 是一个有效的完整目标 × 已经超出了边界范围 × 已经超出了边界范围 × 是一个业务规则，限定业务的条件总结总结用例是系统执行的动作序列，产生特定参与者可看得见的结果值 用例图包含3个部分： ①参与者（Actor） ②用例（Use Case） ③关系：关联、扩展、包含和泛化 用户之间的服务和交互是使用用例图描述的 通常这些图是在建立系统模型时首先要绘制的图练习练习从以下几个题目中选择一个，分析系统功能，建立用例图。 为学校餐厅及周边餐馆提供网上订餐服务 建立校内旧货转让网上市场 在校内开设一家小超市，并提供网上订货及送货上门服务