《UML大战需求分析》阅读随笔（六）

在我们做的代码设计中分为系统设计和程序设计。程序设计是系统设计中模拟程序的执行逻辑，定义客户机服务器对象合作的框架的那个部分。程序和事务设计中，作者讲述到程序和事务设计将系统设计制品放在一起，并作为系统设计过程的最终阶段。

程序设计是系统设计的一个内在的部分。图形用户界面（GUI）和数据库的设计体现出了一个框架的前段和后端。而我们的程序设计就是填充在这框架中间的空缺，并将它转换为可以交给程序员去进行开发的设计文档。那么，怎么样的程序被称为一个好的程序呢。首先，一个好的程序设计要保证类的内聚和耦合的良好平衡。就像之前所说的好的内聚意味着弱的耦合，反过来一个号的耦合意味着弱内聚。所以我们要做的就是让着两者之间达到一个好的平衡。作者接着就为我们讲述了一系列方法来让我们进一步不断的做好，并且通过实例说明。在处理好内聚和耦合的平衡之后，我们就要设计客户机与我们的服务器之间的合作。为了数据和数据库的交互，客户机程序必须使用类似于sql语言的语句来存储和修改数据。而sql可以用五种不同的形式出现并可以用于程序抽象的不同层次上。每一个层次用相同的也有各自的优点。说老说去，也就是对数据的存储之类的功能。触发器，是一种特殊的存储过程，他不能被调用。他在一个数据库表上发生的插入、更新或删除等事件时将他们自己触发。这就 以为这每个数据库表可以最多有三个触发器。在我们进行程序设计的时候，有了数据库的出现我们的对象就自然而然的增加了不少，并且其合作交互也变得复杂了许多。而我们，就不能仅仅是依靠窗口导航图了，而要扩展为更为完整的程序导航图。为了实现一个完整的程序导航图，我们需要对UML的活动图增加服务器端的构造型。而且构造型必须考虑数据库管理系统（DBMS）模型或者甚至是特定的DBMS的特性。除了讲到程序设计，事务设计也是必不可少的。失误是工作的一个逻辑单位，它包含一个或多个由用户执行的sql语句。事务也是数据库一致性的单位，数据库的状态在事务完成之后还是一致的。为了保证这个一致性，DBMS的事务管理有两个作用：数据库回复和并发控制。而事务又分为短事务和长事务。传统的数据库应用要求短事务，一些新的数据库应用则用长事务来工作。

变化管理是整个项目管理的基本方面，变化请求必须记录在案，每个变化对开发制品的影响都必须跟踪，并且在变化实现之后要进行测试。关于测试呢一共分为系统服务测试和系统约束测试两种。系统服务测试可以是基于非执行的或基于执行的。基于非执行的测试包括走查和检查。而基于执行的测试可以是针对规格说明的测试或针对代码的测试；系统约束的测试包括大量的完全不同的测试，它们关系到像用户界面、数据库、授权、性能等等。系统约束测试是与系统服务测试并行进行的，另外一些则是独立完成的。测试和变化管理要求特定的文档，如测试计划、测试用例文档、故障和改进文档等。测试需求在测试文档中表示，并且被连接到用例文档中的用例需求。请求变化一般要么是故障要么是改进。一个变化管理工具用于变化请求的提交并保存它的轨迹，就跟开发者对待它一样。

总结这本书所讲，首相让我知道了一个软件项目的开发需要经历的过程和过程中用到的辅助工具。还有对于项目规划我们可以采用什么样的方法，并且对于软件项目生命周期的认识和理解。然后作者用了好几章的内容讲需求，从需求的分析，需求的不断变更，确定以及需求规格的说明。由此可以看出对于我们软件工程师来说，需求对于我们来说是无时无刻不缠绕着我们的，对于需求的分析我们一定要熟知熟练。而后面的内容，作者则是根据我们开发软件项目的时候不同领域，不同阶段的东西给我们进行讲解。总的来说，在读这本书的时候，自己一直在学习新的不知道的东西。对我们软件项目的开发有了一个大致的理解，这对于我现在、以后做东西的完美性来说毫无疑问是一个强大的理论基础。