基于SSH框架的在线考勤系统开发的质量属性

我要开发的是一个基于SSH框架的在线考勤系统。

　　质量属性是指影响质量的相关因素，下面我将分别从6个系统质量属性（可用性，易用性，可修改性，性能，安全性，可测试性）来分析我的系统，以及如何实现这些质量属性。

可用性：

　　可用性是指系统正常运行时间的比例，是通过两次故障之间的时间长度或在系统崩溃情况下能够恢复正常运行的速度来衡量的。可用性关注的问题有：如何检测故障？发生故障的频度？出现故障时的现象？系统故障排除的时限？如何防止故障的发生？发生故障时的处理？

　　我采用的可用性战术有：

• 错误检测（用来检测故障的健康监视），用于检测错误的3个战术是：信号/响应、心跳、异常。

　　  我的对策：

　　　　  在可能会抛出异常的代码段中使用良好的try{……} catch{……}语句包围。

　　　　  将错误在语义上转换为可以被处理的形式。

　　　　  定义标记变量，定时检查标记变量的值（true/false），来判断是否出现了错误。

• 错误恢复（检测到故障时的恢复），用于错误恢复的战术有7种：表决，主动冗余，被动冗余，备件，shadow操作，状态再同步，检查点/回滚。

        我的对策：

　　　　  定期备份数据库和日志。

　　　　  定期检查日志是否有错误。

• 错误预防（阻止错误演变为故障），用于错误预防的战术有3种：从服务中删除，事务，进程监视器。

　　  我的对策：

　　　　  操作数据库的时候使用事务操作，保证数据的一致性。

易用性：

　　易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。易用性包含易理解性、易学习性和易操作性。

　　易理解性：指用户认识软件的结构、功能、逻辑、概念、应用范围、接口等的难易程度。

　　易学习性：指用户学习软件应用(运行控制、输入、输出)的难易程度。

　　易操作性：指用户操作和运行控制软件的难易程度。

　　我采用的易用性战术有：

• 运行时战术（一旦系统执行，就可以通过为用户提供关于系统正在做什么的反馈，以及为用户提供发出基于易用性命令的能力来增强易用性）

　　  我的对策：

　　　　  功能名称、图标、提示信息等应该直接明了，没有歧义，让用户一看就知道是干什么的，而不是猜测其作用。

　　　　  保持页面的风格是一致的，要求用户进入操作界面后一目了然，能很直观容易的找到自己要使用的功能菜单，方便的完成操作。

　　　　  人机界面友好、界面设计科学合理以及操作简单，合理的默认值和可选项的预先设定，避免了过多的手工操作。

　　　　 操作或处理错误的提示信息明确。

• 设计时战术（提供对当前用户接口设计的修改）

　　  我的对策：

　　　　  将用户接口与应用的其余部分分离开来。

可修改性：

　　可修改性是指实现、测试和部署变更的难易程度。我们要控制实现、测试和部署变更的时间和成本。

　　我采用的可修改性战术有：

• 局部化修改（减少由某个变更直接影响的模块的数量），其战术有：维持语义的一致性，预计期望的变更，泛化模块，限制可能的选择。

　　  我的对策：

　　　　  定义相应的POJO类，实现对象结构的统一。

　　　　  维持语义的一致性，意义相同的属性采用同一变量名。

• 防止连锁反应（限制对局部化的模块的修改），其战术有：信息隐藏，维持现有的接口，添加接口，添加适配器，提供一个占位程序A，限制通信路径，仲裁者的使用。

　　  我的对策：

　　　　  外界不需要使用的属性定义为 private，对外界透明，起到了信息隐蔽的作用。

• 推迟绑定时间（控制部署时间和成本）， 推迟绑定时间可以支持部署时间和允许非开发人员进行修改这两个场景，但需要额外的基础结构来支持后期绑定。

性能：

　　性能是指系统的响应能力——即对外部刺激(事件)做出反应时所需要的时间或在某段时间内所处理的事件个数。影响性能的因素：事件源的数量和到达模式。一般用等待时间、处理期限、系统吞吐量、响应抖动（等待时间的变化）、未处理事件(由于系统太忙无法响应)、丢失数据（由于系统太忙）等指标了解系统性能。

　　性能战术的目标就是对在一定的时间限制内到达系统的事件生成一个响应。就是要控制生成响应的时间。

　　影响响应时间的两个因素：资源消耗（每个事件都要经过一定的处理序列；某种形式的数据转换；根据某个算法进行处理），闭锁时间（由于资源争用、资源不可用或长时间计算导致事件无法处理，这时指计算机可能等待的时间）。

　　我采用的性能战术有：

• 资源需求

　　  我的对策：

　　　　  提高计算效率，减少计算开销。

　　　　  管理事件率，控制采样频率。

　　　　  限制执行时间，限制队列的大小。

• 资源管理

　　  我的对策：

　　　　  引入并发，维持数据或计算的多个副本，增加可用资源。

• 资源仲裁

　　  我的对策：

　　　　  合理的调度资源。

　　　　  减少处理一个事件流所需要的资源，采用 hibernate 框架对数据库进行增删查改操作。

安全性：

　　我采用的安全性战术有：

• 抵抗攻击

　　  我的对策：

　　　　  对用户进行身份验证。

　　　　  对用户进行授权。

　　　　  维护数据的机密性：对传输数据进行加密。

　　　　  维护完整性：对数据提供检验。

　　　　  限制暴露的信息。

　　　　  限制访问。

• 检测攻击

　　  我的对策：

　　　　  监控用户和系统的活动。

　　　　  查找非法用户和合法用户的越权操作。

　　　　  检测系统配置的正确性和安全漏洞。

　　　　  评估关键系统和数据的完整性。

　　　　  识别攻击的活动模式并向网管人员报警。

　　　　  对用户的非正常活动进行统计分析，发现入侵行为的规律。

　　　　  操作系统审计跟踪管理，识别违规的用户活动。

　　　　  检查系统程序和数据的一致性与正确性。

• 攻击恢复

　　  我的对策：

　　　　  对密码、访问控制列表和用户资料数据进行冗余。

　　　　  应用到系统中的数据的所有事务和识别信息的一个副本，可以使用它来识别攻击者的操作，支持认可和系统恢复。

可测试性：

　　可测试性允许在完成软件开发的一个增量后，较轻松地对软件进行测试。

　　我采用的可测试性战术有：

• 记录/回放（捕获跨接口的信息，并将其作为测试专用软件的输入）
• 接口与实现分离（占位实现允许在缺少被占位组件时，对系统的剩余部分进行测试）
• 特化访问路线/接口（允许通过测试工具并独立于其正常操作，来捕获或指定组件变量的值）

• 内部监视（组件可以根据内部状态实现战术，以支持测试过程）