从需求分析到概念原型——针对Github的软件开发项目
需求分析就是需求分析师对用户期望的软件行为进行表述,并进一步用对象或实体的状态、属性和行为来定义需求。这篇博文的主要内容其实就是通过需求分析来得到概念原型的一个过程,即针对我个人的工程实践项目,进行用例建模和业务领域建模,以及数据建模,最终形成概念原型。
一、初步的需求文档
1、项目介绍
本项目是基于Java和flutter开发一个面向github用户的安卓应用程序,可以给用户提供github.com网页上能够提供的常用功能。
2、 功能需求
-
实现登录和登出(获取github鉴权)
-
查看用户信息
- 查看个人信息、个人活动列表、个人动态、个人星标版本库列表等等
- 关注、取消关注用户
-
查看版本库信息
- 查看项目的信息、文件、提交列表、活动列表
- 星标、克隆和关注版本库
-
查看其他信息
-
查看通知和问题
-
查看书签、主题、足迹和全球动态
-
查看趋势版本库和版本库集合
-
搜索
- 搜索版本库的信息
- 搜索用户的信息
-
设置软件信息(如语言、主题等等)
3、质量要求
- 无内存泄漏,操作期间无crash
- 代码风格一致且规范,代码具有高扩展性和可维护性
- 最终交付的产品交互和视觉保持和市面上已经成熟的开源项目大致相同
4、过程约束
-
使用Github v4版本的API基于Flutter的最新框架来实现Android端的APP
-
实现基于Flutter的性能检测工具(帧率、页面打开时长、首帧渲染时长、可交互时长),对业务代码无侵入
二、用例建模
用例:用例是一个业务过程。在待开发软件所处的业务领域内完成特定业务任务的一系列活动就是业务过程。
某个参与者触发某个用例为相应的参与者完成一个业务任务。
扩展用例:需要将参与者和待开发软件系统为了完成用例所规定的业务任务的交互过程一步一步详细地描述出来,一般我们使用一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来。
用例建模的基本步骤:
第一步,从需求表述中找出用例,往往是动名词短语表示的抽象用例。
第二步,描述用例开始和结束的状态,得到高级用例。
第三步,对用例按照子系统或不同的方面进行分类,描述用例与用例、用例与参与者之间的上下文关 系,并画出用例图。
第四步,逐一分析用例与参与者的详细交互过程,完成一个两列的表格将参与者与待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
画出项目完整的用例图如下所示:


三、业务领域建模
业务领域建模有助于开发团队获取业务领域知识。
开发团队获取业务领域知识的过程一般包括:
- 收集应用领域相关信息
- 执行团队头脑风暴:从上一步收集的信息中按规则识别业务领域相关的概念,并分别列出。
- 对业务领域相关的知识概念进行分类
- 用UML类图将业务领域知识图形化展示。
UML类图

四、数据建模
由于字段和实体类过多,可能有部分遗漏,但是选取有代表性几个,其余没添加的实体类和字段都是和本文中已经描述过的类似。
user :
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| name | String | 用户昵称 |
| login | String | 用户登录名 |
| regTime | Date | 注册此账号的时间 |
| activity | ArrayList[Activity] | 该用户产生的所有活动 |
| trending | ArrayList[Trending] | 当前github的所有趋势版本库信息 |
repository :
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| name | String | 包含持有者名称在内的仓库名 |
| description | String | 关于此项目的描述信息 |
| createTime | String | 项目的创建时间 |
| mLanguage | String | 项目中使用比例最大的语言名称 |
| size | String | 此项目的大小 |
enroll:
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| option | String | 用户对版本库采取的操作类型 |
| owner | Boolean | 当前用户是否持有该版本库 |
| forkFlag | Boolean | 当前用户是否克隆了此版本库 |
| watchFlag | Boolean | 当前用户是否关注了此版本库 |
| starFlag | Boolean | 当前用户是否星标了此版本库 |
activity:
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| name | String | 活动的执行者 |
| avataUrl | String | 活动执行者的头像图片地址 |
| time | Date | 活动发生的时间 |
| action | String | 活动的类型:如push star等等 |
| message | String | 活动的具体内容 |
trending:
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| name | String | 版本库名称 |
| trendingTime | Date | 版本库所处的趋势时间范围 |
| chosnLan | String | 版本库的语言 |
五、概念原型
概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论,概念原型是一种虚拟化的、理想化的软件产品形式。也就是说,概念原型 = 用例 + 数据模型。
因此基于以上分析和建模,我们就可以总结出此项目的概念原型,同时对此概念模型的工作过程进行分析。
整个概念模型的工作过程为:
用户这个用例向登录系统输入用户名和密码,登录系统经过处理之后选择允许或不允许用户登录。用户登录后,可以向系统输入条件和数据,系统经过分析和筛选得到版本库、用户、其他等多种信息,版本库和用户之间为关联关系,大部分信息类和用户或版本库之间都为聚合关系,系统经过信息处理之后,会把中间结果转化为组中结果返回给用户,用户收到了满意的结果,这就是一次业务过程。
或者是,用户这个用例在登录之后,可以针对版本库进行操作,版本库被星标、克隆或关注,经过系统的处理之后,会把结果返回给版本库持有者,持有者收到信息,这也是一次业务过程。
再比如,用户在登陆之后,可以对用户进行操作,关注某个用户或者是取消关注某个用户,经过系统处理之后,会把结果返回给被关注或者是被取消关注的用户,用户收到信息。
六、总结
此博客主要根据软件工程的概念原型建模原理,对工程实践项目进行了用例建模、业务领域建模和数据建模,最后总结出概念原型以及工作过程。

浙公网安备 33010602011771号