需求分析与系统设计（三）

写到这里也算是本书的完结篇了，放到上中下里面就是下的概念，在章节末尾写一些我读此书感到受益的部分和相关的知识。

在课上经常听到老师说一些关于软件需求规格说明书的内容，关于需求规格说明，需求规格说明涉及对需求确定期间定义的客户需求进行严格的建模，重点放在那些系统将要提供的所期望的服务上。在规格说明阶段通常不对系统约束做进一步的考虑，但系统约束可以指导和验证建模工作。这种指导和验证采取体系机构优先权的形式。

软件体系结构定义了系统中相互作用的软件构件及子系统的结构和组织形式。书中引用一系列比较晦涩的词汇，确实难以看懂但可以进行罗列比如实现继承的恰当使用扩展继承，uml在以泛化调整继承以及恰当的使用实现继承方面都是非常独特的。继承的唯一恰当使用就是将继承作为类的增量式定义。子类具有比超类更多的特性。子类是超类的一种。这也是通常所说的扩展继承。在扩展继承中，特性的重载要谨慎使用，应该只允许使用特性更特殊化（如限制值得范围或使操作的实现更高效），而不改变特性的含义。如果重载改变特性的含义，则子类对象就不能替换超类对象了。用新的特性扩展子类的定义。然而，有些继承来的特性在子类中被禁止，因此使用继承作为一种限制机制也是可能的，这样的继承被称为限制继承。一味的强调实现继承，可能会在软件模式的使用中造成软件的复杂性增加，但我们不使用继承，那还要它有什么用呢！有人曾言只要我们禁止方便继承就万事大吉了。实现继承按很多标准来说都是一件有风险的事情。如果不被适当地控制和管理，继承会被过度使用以致滥用而产生问题，这些问题应该首先解决。这一点对具有几百个类、几千个对象、对象状态动态变化以及演进的类结构的大型系统（如企业信息系统）开发来说尤是如此。在源程序中有基类，有调用，但往往基类会是非常脆弱的，往往使用不当就会bug频频，问题是指，在允许对超类（或多个超类，如果使用的是多重继承的话）的实现进行演化的同时，使其子类仍然有效并可用的问题。这在任何情况下都是一个严重的问题，特别是当我们考虑可以从系统开发团队的控制范围之外的外部资源中获取超类的时候，更是如此。考虑到这样的情景，你的应用继承了一些超类，而这些超类构成了操作系统、数据库系统。包可见性是java默认的。如果对java的属性或操作没有指定private、protected或public关键字（或对整个类没有指定public关键字），那么它们默认取得的可见性就是包可见性。包可见性意味着包中所含的所有其他类都可以访问这样的一个属性或操作。但是对所有其他包中的类来说，这个属性、操作或类看起来是私有的。保护的（和公共的）也具有包访问性，但反过来并不成立。这意味着同一包中的其他类能够访问保护特性，但如果派生类和基类处于不同的包中，派生类就不能访问那些具有包可见性的特性。

设计数据库访问和事务，应用程序需要与数据库交换数据，客户端程序必须采用数据库语言（通常为sql）来访问和修改数据库。资源子系统（以及rreader、rwriter等类）负责与数据库通信。然而，模型没有说明如何实现通信，此外，模型也没有解释如何保证业务事务的一致性。sql程序设计的层次，为了弄清楚客户端程序与数据库服务器是如何通信的，我们就要认识到sql可以表现为不同的形式，并且可以在程序设计抽象的不同层次上。第一次sql用做数据定义语言ddl。ddl是定义数据库结构（数据库模式）的规格说明语言。数据库设计者和数据库管理员dba是第一层sql的主要用户。第二层sql用做数据操纵语言dml或查询语言。然而，查询语言这个术语有点用词不当，因为第二层sql不仅能够用来查询数据，而且还能够用来修改数据。为保证查询能返回正确的结果，必须让程序员能够逐渐浏览查询所返回的记录，然后依次一个记录地决定如果处理这些记录。这种一次一个记录地处理能力称为临时表，而且第二层以上的sql都有这个功能。