需求规格说明书
- 上次的《需求规格说明书》初稿有哪些不足?
- 上周是我们敲定最终实现什么类型的app,并一起为之提供想法完善内容的第一周,我们大家对我们最终应该完成什么还只是有一个大概的概念,因此需求规格说明书也只是有个框架,其中的诸多内容(例如:用例图,软件和界面的验收标准)上周我们还无法补充进去,只是空有一个写着自己要向什么方向努力的框架。
- 本周对《需求规格说明书》的修改:
- 1.《需求规格说明书》中的修改在Markdown文件中的体现
Markdown
PDF - 2.绘制了该app的功能介绍图
- 3.参考其他标准的《需求规格说明书》,描写了具体用户的使用场景和用户需求分析。
团队的编码规范
1.命名规则(前五条为基本原则,后五条为具体规定)
- 一、使用可以准确说明变量、字段、类、接口、包等完整的英文描述符;
例如,采用类似 FirstName,ListAllUsers 或 CorporateCustomer 这样的名字,严禁使用汉语拼音及不相关单词命名
- 二、采用该领域的术语;
例如:图中的顶点用Vertex而非Point;
- 三、尽量少用缩写,但如果要使用,也请使用公共缩写和习惯缩写等;
例如:广度优先搜索按规范应为:BreadthFirstSearch可简写为BFS;
- 四、避免使用相似或者仅在大小写上有区别的名字。
例如:避免I和l在其中反复出现的名字。
- 五、命名应尽可能简短。
例如:如上第四条中长度超过15个字符的,可以使用公共缩写和习惯缩写。
- 六、包命名:
包名一律小写, 少用缩写和长名;
例如:package javafoundations;
- 七、类或接口命名:
类或接口名是个一名词,采用大小写混合的方式,每个单词的首字母大写,其中,规定抽象类前加Abstract异常类后加Exception。
例如:AbstractJobs/EmptyCollectionExceptions
- 八、变量命名:
采用大小写混合的方式,第一个单词的首字母小写,其后单词的首字母大写;
变量名不应以下划线或美元符号开头;
反例:$name或_name
尽量避免单个字符的变量名,除非是一次性的临时变量。临时变量通常被取名为i,j,k,m和n,它们一般用于整型;
c,d,e,它们一般用于字符型;
组件或部件变量使用其类型名或类型名缩写作其后缀;
例如:fileMenu;
集合类型变量,例如数组和矢量,应采用复数命名或使用表示该集合的名词做后缀。
- 九、常量命名:
全部采用大写,单词间用下划线隔开。
例如:MAX_NUMBER_COUNT;
- 十、方法命名:
方法名是一个动词,采用大小写混合的方式,第一个单词的首字母小写,其后单词的首字母大写;
取值类可使用get前缀,设值类可使用set前缀,判断类可使用is(has)前缀。
例如:setName;
2.代码风格
1.缩进:
程序块要采用缩进风格编写,缩进只使用TAB键,不能使用空格键(编辑器中请将TAB设置为4格);
方法体的开始、类的定义、以及if、for、do、while、switch、case语句中的代码都要采用缩进方式;
2.对齐:
程序块的分界符左大括号"{" 和右大括号"}"都另起一行,应各独占一行并且位于同一列;
对齐只使用TAB键,不使用空格键;
不允许把多个短语句写在一行中,即一行只写一条语句;
if、for、do、while、case、switch、default等语句自占一行;
不论if、for等语句后面跟的语句数是否为1,均需要打大括号。
3.换行:
一行的长度超过80个字符需要换行,换行规则如下:
在一个逗号后面断开;
在一个操作符前面断开;
长表达式要在低优先级操作符处划分新行;
新行缩进2个TAB。
4.间隔:
类、方法及相对独立的程序块之间、变量说明之后必须加空行;
关键字之后要留空格, 象if、for、while 等关键字之后应留一个空格再跟左括号"(", 以突出关键字;
方法名与其左括号"("之间不要留空格, 以与关键字区别;
二元操作符如" >="、" <="、" +"、" *"、" %"、" &&"、" ||"、" <<" ," ^" 等的前后应当加空格;
一元操作符如" !"、" ~"等前后不加空格;
for语句中的表达式应该被空格分开。
5.包的导入:
整个包导入,然后根据自己的需要进行修改,切忌擅自删除包内内容;
3.注释
1.文件注释:
1.文件注释:所有的源文件都应该在开头有一个注释,其中列出文件的版权声明、文件名、功能描述以及创建、修改记录:
例如:
/**
*Copyright(C)2019-2020 Android APP Set;
*FileName:app.java
*Description:java
*History:
*版本号 作者 日期 简要操作
*1.0 王振澳 2019/12/1 Create
**/
2.类或接口注释:
采用JavaDoc文档注释,在类、接口定义之前应当对其进行注释,包括类、接口的描述、最新修改者、版本号、参考链接等;
注:JavaDoc文档注释:描述Java的类、接口、构造方法、方法、以及字段。每个文档注释都会被置于注释定界符/...*/之中,一个注释对应一个类、接口或成员。该注释应位于声明之前。文档注释的第一行(/)不需缩进,随后的文档注释每行都缩进1格(使星号纵向对齐)。
例如:
/**
*测试类(类功能的描述)
*@author wangzhenao(最新的作者)
*@version 1.0(最新版本号)
*@see Java(参考资料)
**/
3.注释格式:
单行注释格式//
多行注释格式/……/
注:单行注释上方空一行,以明确注释的作用域;
4.选择理由
- 1.提高我们的编码效率。整齐划一的代码方便我们进行复制粘贴嘛!
- 2.提高代码的可读性,使得开发人员能够更容易的理解代码。
- 3.方便团队协同工作。大家使用同一的规范,这样就消除了五花八分的书写方式,同一协调!
- 4.养成写规范代码的习惯,有助我们的成长。
团队项目的数据库设计
- 数据库设计
- ER图
项目的后端架构设计
- 主页面
- 全部习惯(尚未完成)
- 番茄钟
- 名人名言
- 百度
团队分工
成员 | 分工 |
---|---|
吴东泽 | 博客的撰写,画各种图,协助姬旭 |
王振澳 | api的调用及实现 |
杨凯涵 | 服务器的搭建及分配任务 |
曹骞 | 界面设计 |
姬旭 | 各个按钮的调用,页面的实现 |
- 根据情况具体动态分配
象限法确定优先级
- 功能介绍图(WBS):
TODOList及燃尽图
-
TodoList任务树
-
燃尽图
本次分工及工作量比例
学号 | 成员 | 分工 | 比例 |
---|---|---|---|
20182312 | 吴东泽 | 博客的撰写,画各种图 | 20% |
20182318 | 王振澳 | api的调用及实现 | 20% |
20182321 | 杨凯涵 | 核心代码的实现及分配任务 | 20% |
20182323 | 曹骞 | 界面设计 | 20% |
20182334 | 姬旭 | 布局及界面美化 | 20% |
本周小组会议及交互总结
- 随着时间愈发的邻近,我们不仅讨论的时间减少了,而且积极性方面也较之前有了一定程度上的下降,频繁的碰壁,让我们对自己的方向感到迷茫,但我们正竭尽全力克服这一困难。
- 在本周中,我们组的人都顺利完成了自己的任务,杨凯涵同学为我们分配的任务,并身先士卒的搭建服务器和数据库,可惜碰壁了,但本周基本任务即代码已完成,姬旭同学完成了页面之间的调用,曹骞同学完成了页面设计,吴东泽同学完成了本周博客和其中的所有要求事项,并对他们的工作进行了一定程度的协助,王振澳同学在api方面已经成功运行,只差将其连接到我们的app中。