0.前言
本文基于在《高级软件工程》课程中所学的软件工程建模方法,对工程实践项目--校园二手交易论坛微信小程序开发进行用例建模,绘制业务类图,数据建模,最终形成概念原型,一方面是对课程中所学知识的进一步掌握吸收,另一方面也为工程实践之后的项目完成打下基础。
1.项目简述
此次项目是基于微信小程序的校园二手交易论坛项目,用于校园范围内的二手商品交易和论坛交流,主要功能包括:商品交易,商品交易,论坛发布等功能。
2.用例建模
用例(Use Case)的核心概念中首先它是一个业务过程(business process),经过逻辑整理抽象出来的一个业务过程,这是用例的实质。在待开发软件所处的业务领域内完成特定业务任务(business task)的一系列活动就是业务过程。
用例有以下几个基本要素:
1.一个用例应该由业务领域内的某个参与者(Actor)所触发。
2.用例必须能为特定的参与者完成一个特定的业务任务。
3.一个用例必须终止于某个特定参与者,也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。
2.1用例建模的基本步骤
第一步,从需求表述中找出用例,往往是动名词短语表示的抽象用例;
第二步,描述用例开始和结束的状态,用TUCBW和TUCEW表示的高层用例;
第三步,对用例按照子系统或不同的方面进行分类,描述用例与用例、用例与参与者之间的上下文关系,并画出用例图;
第四步,进一步逐一分析用例与参与者的详细交互过程,完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
其中第一步到第三步是计划阶段,第四步是增量实现阶段。
2.2对项目进行用例建模,绘制用例图
本项目的参与者(actor)可以分为普通用户和管理员两种类型,因此分别对这两种参与者进行用例建模:
1.普通用户的用例建模如下图所示:
2.管理者的用例建模如下图所示:
3.业务领域建模
3.1业务领域建模概念
业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中,他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景,这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。
开发团队获取业务领域知识的过程一般包括收集业务领域相关信息、执行团队头脑风暴、对业务领域相关的知识概念进行分类,最后用UML类图将业务领域知识图形化展示。
3.2类和对象UML图以及常见关系
需求中业务领域内的名词或名词短语可能是一个类(Class)或者属性(Attribute)。因此在进行业务领域建模时,区分出类和属性是非常重要的一步。
一个对象作为某个类的实例,在业务领域内是能够独立存在的,属性往往不能独立存在。
类和对象的UML的基本画法表示如下:
业务领域中两个概念之间的关系可以分为三类,分别是:继承关系,聚合关系和关联关系
1.继承关系:继承关系表达着两个概念之间具有概括化/具体化(generalization/specialization)的关系。一个概念比另一个概念更加概括/具体。比如车辆是是小汽车的概括,小汽车是一种具体的车辆类型。所以继承关系也被称为“是一种”(IS-A)关系;
2.聚合关系:聚合关系表示一个对象是另一个对象的一部分的情况。比如发动机引擎是小汽车的一部分。也被称为“部分与整体”(part-of)的关系;
3.关联关系:关联关系表示继承和聚合以外的一般关系,是业务领域内特定的两个概念之间的关系,既不是继承关系也不是聚合关系。
3.3业务领域建模基本步骤
第一步,收集应用业务领域的信息。聚焦在功能需求层面,也考虑其他类型的需求和资料;
第二步,头脑风暴。列出重要的应用业务领域概念,给出这些概念的属性,以及这些概念之间的关系;
第三步,给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
第四步,将结果用 UML 类图画出来。
3.4项目的业务领域建模
根据分析,目前所需的类有普通用户类,管理员类,商品类,帖子类,评论类;分别分析其属性和方法及类之间的关系,绘制UML图如下所示:
4.数据模型设计
4.1MongoDB简介
MongoDB是一个通用的、基于文档的、分布式的数据库,为云计算时代的现代应用程序开发者而生,没有数据库比MongoDB在应用开发效率上更加高效。
MongoDB是一种文档数据库,也就是说MongoDB用类似JSON格式的文档来存储数据。目前普遍认为JSON格式是理解和存储数据最自然的方式,JSON格式比传统的关系数据模型有更强大的数据表达能力。
4.2项目的数据模型
用户表:
字段名 | 类型 | 注释 |
---|---|---|
id | int | 用户id |
name | string | 用户昵称 |
phone_number | string | 用户手机号 |
email_address | string | 邮箱地址 |
wx_id | string | 用户微信账号 |
student_number | string | 用户学号 |
school_name | string | 学校名称 |
管理员表: | ||
字段名 | 类型 | 注释 |
---- | ---- | ---- |
id | int | 管理员id |
name | string | 管理员昵称 |
phone_number | string | 管理员手机号 |
email_address | string | 邮箱地址 |
wx_id | string | 管理员微信账号 |
student_number | string | 用户学号 |
商品表: | ||
字段名 | 类型 | 注释 |
---- | ---- | ---- |
goods_id | int | 商品id |
user_id | int | 发布商品的用户id |
name | string | 商品名称 |
price | int | 商品价格 |
image | string | 商品图片地址 |
publish_time | string | 发布时间 |
type | string | 商品类型 |
information | string | 商品信息描述 |
reply_number | int | 评论数量 |
论坛表: | ||
字段名 | 类型 | 注释 |
---- | ---- | ---- |
post_id | int | 论坛id |
user_id | int | 发布论坛的用户id |
name | string | 论坛名称 |
image | string | 论坛图片地址 |
publish_time | string | 发布时间 |
type | string | 论坛类型 |
information | string | 论坛内容 |
reply_number | int | 评论数量 |
回复表: | ||
字段名 | 类型 | 注释 |
---- | ---- | ---- |
reply_id | int | 回复id |
item_id | int | 所属商品或论坛的id |
user_id | int | 发表评论用户的id |
publish_time | string | 评论时间 |
information | string | 评论内容 |
5.概念原型总结
概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论,而概念原型是一种虚拟的、理想化的软件产品形式。
如下是概念原型的具体定义:
概念原型=用例+数据模型,即上文中我们所分析的部分,因此也可以总结出该项目的概念原型工作过程:
项目参与者主要分为普通用户和管理员,普通用户首先进行注册,在管理员审核通过之后可以顺利进行登录,可以从商品页面浏览商品,根据分类选择自己感兴趣的商品,并在感兴趣的商品下评论;也可以在论坛页面浏览论坛并发表评论;同时用户也可以发布自己的帖子和商品,在管理员审核通过之后成功发布。管理员由可以做到和普通用户同样的事情,除此之外,管理员可以审核进行注册的普通用户,通过验证其学校和学号等信息使普通用户使用小程序,并在用户发布其商品或者帖子后进行审核,审核通过之后,该商品或帖子可以在商品页面和论坛页面公开显示。
6.小结
此次博客通过对工程实践项目进行需求分析,不仅加深了对上课所讲内容的理解,同时也对工程实践项目之后的开发有了更加明确的方向。希望可以借助这次机会培养自己的软件工程思维,使自己之后的项目开发更加规范。同时本文章由于自己也并未对知识内容完全理解掌握,错误之处还望老师和和同学们指正。
请发表评论