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

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

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

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

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