找高手帮忙做一个远程终端管理系统必有重谢

鄙视-你 2013-09-14 06:57:04
远程终端管理系统需求分析说明书
一. 引言 1
1.编写目的 1
2. 定义 1
二. 任务概述 2
1.目标 2
2. 用户的特点 2
3. 系统功能示例 2
三. 需求细则 2
1. 对功能的规定 2
2. 对性能的规定 5
3. 对排版的规定 5
4. 对可维护性的规定 5
5. 对个性的规定 6
6. 对项目过程的规定 6

引言
1.编写目的
通过与多位软件使用者进行全面深入地探讨和分析,并完成《远程终端管理系统》市场的前期调查后,提出了这份软件需求分析说明书。
此需求分析说明书对《远程终端管理系统》软件做了全面细致的用户需求分析,明确所要开发的软件应具有的功能、性能与界面,使系统分析人员及软件开发人员能清楚地了解用户的需求,并在此基础上进一步提出概要设计说明书和完成后续设计与开发工作。
本说明书的预期读者为客户、业务或需求分析人员、测试人员、用户文档编写者、项目管理人员。

2. 定义
需求:用户解决问题或达到目标所需的条件或功能;系统或系统部件要满足合同、标准,规范或其它正式规定文档所需具有的条件或权能。而且其很强的交互性及简单易行性,可以让人在很短时间内熟悉它的操作方法,不论用户文化水平如何,都会很轻松的学会使用它。

任务概述
1.目标
2. 用户的特点
由于本程序简单易操作,交互性好,对用户没什么特别要求。一般用户经过几分钟练系都可以熟悉本系统的规则。

3. 系统功能示例

需求细则
对功能的规定
分必选项和任选项,其中,必选项是必须完成的,属于项目答辩的入口条件,所有人都要做,未完成者取消答辩资格;任选项不是入口条件,但每完成一项都会加分,对于完成了必选项的同学,尽可能地多完成一些任选项,以期获得更高的答辩成绩。如果所有项(包括必选和任选)都完成,那么功能分就是满分。如果设计思路、界面效果、代码组织等方面有个性(或和别人的不同),则获得附加分。
1.1 服1.2 务器功能
1.2.1 配置文件
属性:必选
描述:服务器的配置从配置文件中获取,内容包括服务器地址(服务器IP 和 port),具体格式如下:
SERVER_IP = 192.168.1.11
PORT = 12012
注意:具体IP和port以本地为准

1.2.2 账户文件
属性:必选
描述:客户端注册的用户名和密码需要服务器保存。必须完成下列所有情况:
内容为用户名和用户密码列表;
必须用文本形式;
用户注册用户名重复,需要提示重新选择用户名
用户登录时用户名重复,需要提示重新选择用户名
用户名密码输入错误,应该提示。给3次连续错误机会,超过3次退出。


1.2.3 支持多客户端
属性:必选
描述:基于tcp协议的客户端服务器通讯,服务器采用多线程支持多个客户端连接。

1.2.4 服1.2.5 务器与客户端业务功能
属性:必选
描述:建立连接后,服务器能够支持客户端的业务应用,逻辑顺序如下:
客户端从终端接受命令,把命令发送给服务器;
服务器执行命令,并把执行结果返回给客户端;
执行结果在客户端上显示,必须支持至少 “ls -l”“pwd”“ipcs”“ifconfig”等4个命令,在客户端终端键入,服务器将执行结果采用socket返回并显示在客户端。

1.2.6 链表记录会话连接
属性:必选
描述:服务端使用链表记录当前客户端的会话连接,多个线程访问同一个链表,采用互斥锁、信号量来控制。链表包含下列信息:客户端的ip地址、连接时间,用户名。

1.2.7 链表记录动态维护
属性:必选
描述:服务端能够动态维护链表记录;服务器有命令供查询显示。



1.3 客户端功能
1.3.1 注册
属性:必选
描述:客户端提供注册用户名,密码功能,用户名密码通过网络传输到服务器认证(用户名不可重复),认证通过后写入账户文件。

1.3.2 登陆(认证)
属性:必选
描述:服务器和客户端增加用户密码登陆机制,包含如下流程:
客户端把接受的用户名密码发送至服务器;
服务器启动后从配置文件中读取用户信息形成数据表,根据此来验证密码。验证后返回认证结果给客户端(不可一个用户名同时登录)
如果认证正确,服务器开始接受客户端的命令;认证错误重新认证(3次登陆错误退出)

1.4 心跳机制
属性:必选
描述:客户端与服务端之间使用心跳机制,必须完成下列所有情况:
客户端定时向服务端发送一个数据包(心跳包,内容不限,3秒间隔),证明自己活着;
服务端显示来自某个IP地址客户端的心跳包;


1.5 心跳异常
属性:任选
描述:服务器超过一定的时间没有收到客户端的心跳包(3秒间隔),连续5个包没有接收到则说明客户端出现问题,必须做出如下的处理:
记录状况;
断开连接;

1.6 聊天功能
属性:任选
描述:两客户端之间能够直接文字通信(类似于QQ聊天),
能够查询在线列表,具体信息从服务器的链表记录获得;
可以和别的客户端聊天,发数据采用“用户名后面加数据”方式;
amdin#hello
1.7 协议
属性:必选
描述:根据通信数据的类型,重新设计应用协议(数据包)。将上述客户端与服务端之间的通信数据,以协议的形式进行封装。一个示例协议格式如下,按照这种格式来发,供参考:

int data_type
int size
char data[size]

data_type为数据包类型(可以用宏定义),例如如下定义:
TYPE_LOGIN =0, 登陆数据包
TYPE _REG = 1, 注册数据包
TYPE _MSG = 2, 消息数据包
TYPE _HEART = 3 心跳数据包
TYPE _CMD = 4 命令数据包
TYPE_OK =5
TYPE_ERR =6

注意:int数据要转换成网络字节序,否则传输会出问题。

1.8 日志文件
属性:任选
描述:服务端通过一个日志文件记录所有客户端连接、命令执行、断开信息(时间,IP地址,执行的命令,心跳包超时等)。 例如:“客户端连接时间 客户端IP地址 客户端的命令 数据包类型(就是上面1.6的data_type) 客户端发送的信息 ”。

进程守护 makefile 进入命令格式:[用户名@IP dirname]#
管理员:
1 查看日志 2 查看在线用户 3关闭服务器
对性能的规定
本系统在设计方面本着方便、实用的宗旨,性能方面应遵循如下原则:
执行效率(时间): 软件运行应该尽量高效;避免没有必要的循环处理、重复处理;
资源损耗(空间):设计尽量节约资源(内存、数组、链表等);不用的资源要及时释放;
初始化: 变量、数组、内存块、链表节点(其next要置NULL)等都要初始化;
健壮性:不能出现野指针、内存泄露、数组越界访问等等:
申请内存之后,应该立即检查指针值是否为NULL;动态内存的申请与释放必须配对,防止内存泄漏。释放了内存之后,立即将指针设置为NULL,防止产生“野指针”;
函数的入参必须进行有效性判断;用户输入、函数返回值(如果用到的话)都要判断;
switch-case一定要有default;if-else if等后要有else,除非if满足后返回或退出;
不允许出现goto语句;
数组的下标不要发生“多1”或者“少1”操作。


对排版的规定
缩进要对齐;
长行拆分;
二元操作符的前后应当加空格,包括如下操作符:
赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符,如"="、"+=" ">="、"<="、"+"、"*"、"%"、"&&"、"||"、"<<", "^" 等;
空行:
结构体 声明之后、每个函数定义结束之后都要加1行空行;
逻揖上密切相关的语句之间不加空行,其它地方应加空行分隔;
一行代码只做一件事情;
"if"、"for"、"while"、"do"等语句自占一行,执行语句不得紧跟其后。不论执行语句有多少都要加 "{ }";

对可维护性的规定
对可维护性的最终要求:别人能够轻松上手你的代码。
结构清晰:
模块化:对界面(显示)、菜单管理、逻辑管理、文件操作等等代码要独立,必须多个.c文件,用makefile;
封装:一个函数只做一件事,函数功能要单一;一个函数不能超过50行;
避免重复、冗余代码;
代码块清晰。
变量命名规范,变量名应该具有自明性:
常量,枚举和宏定义命名
常量名,宏和枚举值由全大写字母组成,单词间通过下划线来界定;
函数的命名:
使用"动词"或者"动词+名词"(动宾词组)的形式,由一个或多个单词组成且以小写字母开头,以后每个单词之间用下划线隔开
变量的命名与定义
应当使用"名词"或者"形容词+名词",由一个或多个单词组成且以小写字母开头,以后每个单词之间用下划线隔开。
注释充分:变量、函数(包括参数、返回值)、代码功能块、一些复杂算法……等都需要
清晰明了地说明;
...全文
52 1 收藏 回复
写回复
回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
相关推荐
发帖
C语言
创建于2007-09-28

6.4w+

社区成员

C语言相关问题讨论
申请成为版主
帖子事件
创建了帖子
2013-09-14 06:57
社区公告
暂无公告