基于Github手机应用的需求分析与概念原型设计
基于Github手机应用的需求分析与概念原型设计
一、项目概述
- 本项目基于Android和Flutter的混合开发,实现Github的各种功能。主要包括,Login、Star、Fork、Comments、Follow、Clone、Git Branch、添加书签、查看文件树、阅读Markdown文档、切换主题等功能。所需要实现的页面包括Star、Trendings、Notification、News、Repos、Bookmarks、FeaturedTopics以及个人主页和项目主页等。
- 通过GraphQl和Restful向Github请求数据,以实现用户各类信息的显示和操作。集成了Okhttp、Glide、ButterKnife、ARouter、Toasty、Flutter Boot和Flutter Boost等开源框架。
- 对应用进行了全方位的优化,包括
- 调整代码架构,模块拆分为MVP模式,分层架构,降低模块耦合,提高代码复用。
- 集成Leakcanary,优化内存,防止OOM。
- 集成Blockcanary,优化多线程带来的卡顿。
- 布局、渲染优化--调试GPU使界面70%为蓝色,防止过度绘制。
- 优化网络速度,通过连接复用、Gzip压缩、断点续传、请求合并降低网络延时。
二、需求分析概述
通过课上老师的讲解得知,需求分析作为软件设计的第一个步骤,有其独有的重要性,主要体现在,防止要求不完整、缺乏用户参与、规避不切实际的期望,保证有足够的资源,预测变化要求等。几乎所有这些原因都涉及需求过程的一部分如果不及早发现需求错误,可能会造成很大的损失。
此外,不同人员对项目的需求也是不尽相同,想要准确的获取需求,需要通过多个维度和多种手段综合得到。
功能性需求
- 保证用户能够登录github账号
- 实现Profile、Notification、News、Issues、Myrepository、StarredRepository的一级页面,以及项目主页和个人主页的二级页面
- 实现Star、Fork、Comments、Follow、Clone、Git Branch、markdown格式阅读、树形展示文件结构的功能
非功能性需求
- 无卡顿
- 无内存泄露
- 无过渡绘制
- 无内存的抖动
- 无stackOverFlowError
- 可以忍受的页面打开耗时
其它限制(技术的限制、资源的限制、等)
- 技术的限制:
- 由于本项目目前是基于java和flutter的原生开发,很难做到适配Android手机的同时保证所有Ios设备的所有页面均能够正常运作(仅能保证基于Flutter页面能够在Ios中正常运行,没有OOM和ANR)
- 资源的限制
- 由于目前Github的GraphQl,APIv4支持的接口数目并不全,很多页面官方并不提供相应的API,导致有些页面会与Github.com数据有所差异。
- Github在今年的十月份取消了第三方的账户密码登录(处于安全考虑),因此本项目的登录界面只能通过OAuth2.0鉴权获得。
三、用例建模
用例建模的概述
用例建模是指,经过逻辑抽象出的项目交互流程,其中最主要的是参与者、特定的任务、经过特定任务修改后的参与者。其主要的步骤为:
-
寻找用例,在本项目中为:查看、star、unstar、fork、download、comment、bookmarks、search,sort
-
描述用例开始和结束的状态
- TUCBW:用户点击项目中的star按钮 , TUCEW,用户的star列表中加入该项目的信息
- TUCBW:用户再次点击项目中的fork按钮 , TUCEW, 用户的版本库列表中添加该项目的信息
- TUCBW: 用户点击项目中的download按钮 , TUCEW, 开启下载的service将版本库下载到用户的手机
- TUCBW: 用户点击项目中的comment按钮,并添加评论 , TUCEW, 在项目的issue中展示该用户的评论信息
- TUCBW: 用户点击项目中的bookmarks按钮 , TUCEW, 将该项目信息存储到本地的数据库中
- TUCBW: 用户点击项目中的search按钮 , TUCEW, 在官网中寻找响应名称的版本库并返回搜索的结果
- TUCBW: 用户点击项目中的按照...排序按钮 , TUCEW, 刷新列表,从官网调用响应的排序结果返回给用户的手机
-
分类总结并画出响应的用例图:

其中每一种关系如下图所示:

- 详细的交互过程
- 其中的在本项目中页面更新和首页展示之间是关联模式,原因是二者之间没有明显的前后依赖关系,是一种由常识、规则和法律等因素前置约定的
- 用户和登录系统以及展示页面之间用的是单向关联关系,原因是参与者知道要登录,但登录并不知道参与者,同理,展示页面和页面刷新的关系也是一样的
- 本用例图中用的最多的便是include,包含关系,如账户登录和输入密码账户浏览器中打开,页面展示和star、fork、comment等,即在基本的用例中插入包含用例
- 忘记密码和版本库的搜索是extends是扩展关系,即在登录系统中没必要非加入忘记密码这个选项,(用户可以去github官网查看自己账户和密码是否正确),同理页面中的搜索也是扩展的用例
四、业务领域建模
概述:
业务领域的建模主要的目的是帮助开发者获取业务的整体流程,帮助产品与开发之间形成统一的认知。
业务领域建模的流程
- 收集业务领域信息,
- 头脑风暴
- 进行分类归纳总结,理清各个类别之间的逻辑关系
- 以UML类图的方式进行呈现
- 类图的基本关系

项目UML类图
经过对数据的手机、头脑风暴、分类总结后,拟采用mvp分层架构模型,在此基础上用户信息UML类图如下所示

五、数据建模
数据建模即从项目所需的数据结构中抽象出逻辑数据模型,本项目的数据建模如下图所示
repository信息
| 字段 | 类型 | 描述 |
|---|---|---|
| title | String | 项目名称 |
| createdAt | String | 创建的时间 |
| number | int | 有关项目的成员个数 |
| description | String | 有关项目的描述 |
| language | String | 项目所使用的的语言 |
| avatarUrl | int | 项目拥有者 |
| description | String | 有关项目的描述 |
| language | String | 项目所使用的的语言 |
用户信息
| 字段 | 类型 | 描述 |
|---|---|---|
| String | 用户的邮件地址 | |
| name | String | 用户的姓名 |
| avatarUrl | String | 用户的Url头像 |
| login | String | 用户的id,唯一标识 |
| bio | String | 用户的个人简介 |
用户登录鉴权信息
| 字段 | 类型 | 描述 |
|---|---|---|
| client_id | String | 用户的账户 |
| client_secret | String | 用户的密码 |
| code | String | 登录的授权码 |
| state | String | 登录的状态 |
项目的Issues信息
| 字段 | 类型 | 描述 |
|---|---|---|
| createdAt | String | Issue创建的日期 |
| name | String | Issue的名称 |
| description | String | Issue的描述 |
| repository | String | Issue所属的仓库 |
| comments | String | Issues的评论信息 |
| author | String | Issue的作者信息 |
| closed | boolean | 该Issue是否已经解决 |
项目的Notification信息
| 字段 | 类型 | 描述 |
|---|---|---|
| updated_at | String | 更新的日期 |
| author | String | 作者 |
| comment | String | 评论的内容 |
| invitation | String | 加入项目的邀请 |
| manual | String | 用户的个人简介 |
| mention | String | 所提及的信息 |
| state_change | String | 状态改变的信息 |
| subscribed | boolean | 是否订阅 |
| team_mention | String | 团队提及的信息 |
六、概念原型
业务概念原型是指一种虚拟抽象的方法描述项目特点和结论。
经过上述的功能性需求分析和非功能性需求分析、限制、用例图、数据建模、业务领域建模总结出本项目的工作流畅大体如下:
- 用户通过网页登录自己的Github账号,通过客户端的方式查看Github.com中类似的内容
- 在个人主页中展示了自己的用户信息,以及将与用户相关联的repository集成到项目列表中展示了用户所创建、star、关注的项目
- 在repository页面中展示该项目的文件信息、项目简介、commit、star、issues相关的信息
- 用户可以star、fork、follow等操作对Repository发出更改
七、总结
通过这个阶段对于需求分析和软件设计的学习,明白了在真实大型的项目中,开发的过程比以往所作的如图书馆里系统等小的demo有着更为规范和流程化的步骤,正式通过这些重要的步骤,规范了项目的各个方面,使得开发的目标明确、效率提高。
此外通过UML图形绘制,加深了对面向对象的理解,深切体会了对象的设计方式和各个部分之间的逻辑关系。

浙公网安备 33010602011771号