本文基于在《高级软件工程》课程中所学的软件工程建模方法，对工程实践项目--校园二手交易论坛微信小程序开发进行用例建模，绘制业务类图，数据建模，最终形成概念原型，一方面是对课程中所学知识的进一步掌握吸收，另一方面也为工程实践之后的项目完成打下基础。
1.项目简述此次项目是基于微信小程序的校园二手交易论坛项目，用于校园范围内的二手商品交易和论坛交流，主要功能包括：商品交易，商品交易，论坛发布等功能。
2.用例建模用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。
用例有以下几个基本要素：
1.一个用例应该由业务领域内的某个参与者（Actor）所触发。
2.用例必须能为特定的参与者完成一个特定的业务任务。
3.一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。
第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例；
第二步，描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
其中第一步到第三步是计划阶段，第四步是增量实现阶段。
本项目的参与者（actor）可以分为普通用户和管理员两种类型，因此分别对这两种参与者进行用例建模：
1.普通用户的用例建模如下图所示：
2.管理者的用例建模如下图所示：
业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。
开发团队获取业务领域知识的过程一般包括收集业务领域相关信息、执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类图将业务领域知识图形化展示。
需求中业务领域内的名词或名词短语可能是一个类（Class）或者属性（Attribute）。因此在进行业务领域建模时，区分出类和属性是非常重要的一步。
一个对象作为某个类的实例，在业务领域内是能够独立存在的，属性往往不能独立存在。
类和对象的UML的基本画法表示如下：
业务领域中两个概念之间的关系可以分为三类，分别是：继承关系，聚合关系和关联关系
1.继承关系：继承关系表达着两个概念之间具有概括化/具体化（generalization/specialization）的关系。一个概念比另一个概念更加概括/具体。比如车辆是是小汽车的概括，小汽车是一种具体的车辆类型。所以继承关系也被称为“是一种”（IS-A）关系；
2.聚合关系:聚合关系表示一个对象是另一个对象的一部分的情况。比如发动机引擎是小汽车的一部分。也被称为“部分与整体”（part-of）的关系；
3.关联关系：关联关系表示继承和聚合以外的一般关系，是业务领域内特定的两个概念之间的关系，既不是继承关系也不是聚合关系。
第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
第四步，将结果用 UML 类图画出来。