《软件是这样炼成的--从软件需求分析到软件架构设计》 读书笔记

发表于 更新于 分类于

一块大部头，是关于软件工程的一本理论联系实际的指导性质的书，本书最特别的地方是从头到尾都是以一个项目来作为案例，让读者容易理解各个环节之间的来龙去脉。还是不错的一本书，适合有一定基础的读者，相当于从实际案例出发，梳理了一遍整个知识体系。
按照作者的说法，需求开发告诉客户想干什么，架构设计阶段从软件的视角出发，架构了软件对象（或类之间的关系），详细架构设计阶段是根据某个类设计了其具体的设计实现，比如说：每个类的方法体、输入和输出、数据结构和算法、对数据表的操作以及状态改变。
读书笔记脑图下载


一、需求调研

  • 需求关注的是客户的业务流程以及客户处理的数据信息。
  • 调研方式：问卷调查、面谈（到现场调研，不要开大会；收集业务资料；考虑异常）、组织讨论（跨职能部门的流程的确认）
    资料：组织机构、岗位职责、流程、表单（授权）、报表。
  • 静态结构：组织架构、部门职责、岗位职责
    动态结构：流程、运营节点描述、数据表单（如果是合计的项，需要说明数据项的处理逻辑）

二、需求分析












  • 需求分析：动态--用例，考虑人机交互；静态--领域分析，考虑用例操作的对象实体
  • 需求告诉我们做什么，至于怎么做事由架构决定的。
  • 业务流程图作为系统分析需求功能和程序流程的基础，业务对象作为编写领域类图和数据字典的基础；客户调研报告中的组织结构作为子系统划分的依据；岗位职责描述部分作为系统中参与者的设计依据。
  • 用例图，使得客户在大脑中形成了一个系统的运行蓝图，让客户明白能够在将来的系统中扮演的角色以及在这个角色中要承当的责任和客户将运行哪些行为动作完成自己的工作。
  • 用例：业务流程图（分顶层业务流程图、底层业务流程图）中的节点，（运行节点的描述）。
  • 对于复杂的用例，可以考虑适当的使用用例运行流程图补充描述。（基本事件描述流）
  • 用例补充：系统自动处理的用例、系统维护方面的功能。
  • 用例参与者关系分析；分类后作为确认的资料依据；录入的部分一般都是用例的角色。
  • 用例关系的确认最好不在业务报告中获取，最好的方法是在用例描述中获得。
  • 用例的参与者：
    1、谁使用该系统的主要功能；
    2、谁将需要该系统支持以完成其工作；
    3、谁讲维护、管理该系统以及保持该系统处于工作状态；
    4、系统需要哪些硬件设备才能有效运行；
    5、与该系统交互的系统有哪些；
    6、谁或什么系统对本系统产生的结果感兴趣；
  • 用例图描述的是系统该有哪些功能。一般抽取业务调研报告中的动词或者动词词组。
    领域模型来自业务描述中的名词以及对名词的抽象。领域模型是一个分析模型。领域模型只考虑业务描述中涉及的实体以及实体之间的关系。反映的是系统结构的关系图！
  • 领域类图依赖：
    1、原始数据表格；
    2、用例分析报告中用例用到的对象。
    然后归纳整理。
  • 用例描述的粒度把我是所要描述的用例至少有一个实体对象存在。领域类图描述是，所有的描述语言都采取中文描述法，数据属性采取的是中文描述方法，不允许使用计算机专业的语言描述数据属性，是用户能够方便理解的中文描述法。
  • 用例图和类图是两个无法独立的UML图，用例描述提供什么样的服务，而服务的核心（载体）是以领域类的形式表现的。
  • 数据字典的作用：保持一致性、共享性；例如用户和需求分析师、需求分析师与设计人员、不同的系统之间。
    *****面向对象的分析方法中，我们在需求分析阶段没有明确说明要定义数据字典，大部分用领域图来替代。

三、概要设计

  • 建模就是从不同的视角来反映系统的不同侧面，各种视图是互补，以达到完整体现软件系统的目的。UML可以通过不同的视角完成软件的建模工作！
  • 架构是蓝图，蓝图采用4+1模型来分不同角度体现，用UML工具来生成对应的视图。

1、软件架构







  • 软件体系结构本质上讨论的是系统中不同的独立构建存放的位置问题，以及这些构建之间的通信方式。软件体系结构中一般包括通信构件、处理构件和数据构件。UML时序图、活动图、状态图属于逻辑视图，描述的是对象关系，但是，这些UML视图的目标是辅助代码的实现。代码最终以构件的形式存在于具体的物理设备上，这就是我们所说的体系结构。
  • 软件设计系统风格是描述某一特定应用领域中系统的组织方式的惯用模式。
  • 设计模式关注的是类与类之间的关系，是类关系层面上的设计。
    设计模式是一种思想，有些框架是建立在某种模式之上的，是为了完成设计模式而开发的中间件，可以降低开发成本提高开发效率。例如，MVC是一种设计模式，而Struts则是为了实现MVC模式而开发的框架。
  • Struts关注点在表示层，Spring关注点在业务逻辑部分，而Hibernate关注点是数据存储部分。
  • 体系结构比分层设计更为高层一些。
  • 分层是表示将功能进行有序的分组。通过分层，可以限制之系统间的依赖关系，使系统可以更松散的方式耦合，从而更易于维护。
  • 层数越多，可以将每层分布在不同的机器上。
  • 蓝图-- 概要设计；施工图--详细设计
  • 设计模式的核心原则是“开闭原则”，对扩展是开放的，对修改是关闭的。一个好的系统是在不修改源代码的情况下，可以扩展功能。实现开闭原则的关键就是抽象化，在开闭原则中，不允许修改的是抽象的类或接口，允许扩展的是具体的实现类，抽象类和接口在开闭原则中扮演着极其重要的角色。即要预知可能变化的需求，有预见所有可能已知的扩展。
    针对接口编程，而不是针对实现编程。
  • 一般狭义上的业务逻辑不包括数据持久化。
  • 框架：就是半成品，开发人员做填空题。
  • 时序图针对某一用例中对象之间的活动顺序关系，但是有时时序图自身特点决定了系统分析的不完整性，特别是无法满足条件转换、分支和分叉等，活动图刚刚好满足了这样的要求。
  • 活动图能够在类设计层面起到指导编码就足够了。
  • 包可以直接理解为命名空间、文件夹。
  • 组件图应该是用户手册的一部分，知道系统实施人员完成系统的软件部署。
  • 在我们现实开发过程中，如果做到概要设计这详细程度已经足够了。
  • 按照正常情况，程序员应该将70%左右的时间花在程序异常处理中。一个没有考虑异常的系统，就如同没有消防通道的大楼一样。
  • 程序异常包括：
    1、编译错误；
    2、运行时发生错误（可以预料，但不能避免）；
    3、业务逻辑错误（例如出生日期不能大于当前日期）
  • 异常的处理很大程度上揭示了其所基于架构的强度。
  • 输出数据不完整：对于某些系统来说，数据不完整可能比系统停止运行带来更大的损失。较为理想的方法是向输出设备写一些信息，声明数据的不完整性；另一种方法是先缓冲要输出的数据，准备好全部数据之后再一次性输出。
  • 所有异常都未必是用一个简单的弹出窗口或者一个小动作来处理，而是需要比较复杂的流程来完成，这是，就出现了另外一个概念“其它事件流”

2、数据架构



  • 实体关系建模是在解读需求分析报告中领域类图和数据集以及数据字典的基础上，分析并确定实体名称和具体内容，剔除冗余实体、冗余数据项、冗余元组、冗余属性和冗余属性值。结合数据库之设计理念，创建实体卡片，分析其实体关系，绘制实体关系图（ER图）。
    领域类图的元素中包括了对这个领域类的操作，而实体关系图中不包含操作。实体关系图中的对象是建立在领域类的基础上，但是要要对领域类中的数据属性等进行优化，尽量做到减少数据冗余。领域类图是架构设计中时序图、活动图、状态设计图的基础。而实体关系图是数据库设计的基础。
  • 冗余分析：
    1、表冗余
    2、记录冗余
    3、属性冗余
    4、属性值冗余
  • 实体关系图（E-R图）编制一般分两步走，第一步只考虑实体以及他们之间的联系；第二步考虑给定实体的属性，不同时考虑两者是为了让设计工作变得单纯一点。
  • 用建筑设计来比喻的话，实体关系图其实就是建筑材料的挑选过程，也就是说根据用户需求，我们决定需要哪些材料以及这些材料配比关系，争取做到一点都不浪费不冗余。在实体关系建模过程中，我们其实就是对领域类和数据集以及数据项的优化过程，并且确定了他们之间的关系。
  • 在逻辑设计阶段，需要考虑主键、外键、考虑是否为空、是否符合业务规则，数据库范式的分析。
    1、创建表
    映射E-R实体为表、表关系描述、数据完整性（实体完整性--主键约束、参照完整性--外键、用户定义完整性--业务规则）
    2、范式检查表结构
    3、是否满足所有的业务
    4、检查按业务规则
  • 派生数据的设计，在修改源数据的时候很容易导致不一致的情况出现；
    提取表（统计表）：修改源数据的时候，需要考虑冲账的方式，把修改的差异体现在下一个统计周期中！
  • 存储过程出发点：少量输入参数、大量输出数据的情况下，减少数据库服务器为其它应用程序提供服务而带来的网络负荷，提高数据库操作性能。
  • 数据库安全：
    1、管理制度
    2、数据授权
    3、数据库技术：存储过程、视图、加密等。

四、详细设计




  • 领域类图，用例图都是从系统功能和结构的视角来分析系统。但是，这些视图都是围绕着系统的外部结构进行描述的。那么，要使得这个系统能够做好设计，能够为系统开发者提供足够的指导性设计，就必须从系统的本质开始描述，从一个用例的内部结构开始描述，时序图所描述的就是用例内部的对象之间的关系。
  • 用户与系统的交互点是界面。
  • 详细的时序图能够全面表达用例对象交互的顺序额关系，还能够反映出参与者与用例之间的交互过程，而这些过程都反映数据元素的变化过程，从业务的角度考虑，数据元素表现最为完整的部分应该是时序图。
  • 数据结构：一个数据结构是由数据元素依据某种逻辑联系组织起来的。讨论一个数据结构必须同时讨论该类数据上执行的运算才有意义。通常，确定了数据结构之后，算法就容易实现了。
  • 数据，而不是算法，是系统构造的关键因素。这种洞见导致了许多种软件设计方法和程序设计语言的出现，面向对象的程序设计语言就是其中之一。
  • 算法主要的应用场景分为：算法密集型（搜索）、业务逻辑密集型（ERP）、体验密集型（游戏）
  • 优化：
    1、多表之间的关联关系通过视图的方式生成单表视图，这样避免将大量无用数据读到内存中，占用内存资源。
    2、数据库排序后再加载到内存
    3、索引
    4、尽量减少从数据库中提取数据记录数量，为了降低空间复杂度，在数据检索过程中，做到对数据提取的准确定位。
    5、对于方法体返回的数组严格按照实际列宽数据元素数量长度进行定义，保证了开辟内存一点都没有浪费。
  • 详细设计文档要设计到每个类的具体方法！设计单位是类。设计内容是方法体。
  • 衡量索引效率的 95/5 规则：如果查询的结果返回的行数少于表中所有行的5%，则索引是检索数据的最快方法，如果查询的结果超过5%，那么通常使用索引就不是最快的方式。

文章摘录

  • 小软件企业的通病：工期延误，成本增加，质量无保证，员工斗志下降，不断加班却没有效率，员工怨声载道，客户叫苦连天。
  • QS：质量保证，就是软件过程的控制、管理规范及执行监控。
  • 一个公司需要考虑管理架构+技术架构；经营+财务；
  • UML：类似AutoCAD，一种软件设计、建模的工具。
  • 世界的本质其实和类相似，就是对象，对象本身的属性、动作；以及之间的相关关系。
  • 软件设计思想：变与不变分离（可重用），分层思想（降低耦合），抽象（降低复杂度）
  • 面向对象的方法是以认识论为基础，用对象来理解和分析问题空间，并设计和开发出由对象构成的软件系统（解空间）的方法。由于问题空间和解空间都是由对象组成的，这样可以消除由于问题空间和解空间结构上的不一致带来的问题。
  • 聋哑对话
    老虎吃天 ---- 无从下口
  • 继承的主要目的是为了抽象而不是重用和功能扩展