记录督促自己学习3

第六章

第六章主要是介绍软件体系结构概念和体系结构的设计，要点主要是包括软件体系结构设计的重要性，体系结构设计阶段对系统体系结构必须做出的决策，介绍体系结构的模式思想，介绍经验证明有效的、并且能够在系统设计中复用的组织系统体系结构的方法;l了解经常在不同的应用系统类型中使用的体系结构模式，包括事务处理系统和语言处理系统。体系结构设计关心的是理解如何组织一个系统和设计系统的整体结构，体系结构设计是设计和需求工程之间的桥梁，因为它识别系统的主要结构组件以及它们之间的关系。
由于成本等因素限制，敏捷过程中，重构组件来响应变化的方法可行性不高，这一块，我不太能够区分，在软件工程定义下，软件结构设计和软件模型之间的定义或者说，概念具体关系是什么。对于这个问题比较疑惑。
从体量抽象的来讲，可以分成小规模体系结构和大规模体系结构，小规模体系结构与单个程序的体系结构相关，在这个层次上，我们关注将单个程序分解成许多组成部分的方法，大规模体系结构与复杂企业系统的体系结构相关，包括其他的系统、程序和程序组件。
软件体系结构很重要，因为它影响到系统的性能，强壮性、分布能力和可维护性，在某些系统中，非功能需求会受到单个组件影响。明确设计和文档化软件体系结构，的三个好处是：1信息持有者之间的沟通，体系结构是系统的一个高层表示，可以作为不同信息持有者之间讨论的中心，2系统分析，在系统开发的早期阶段明确给出系统的体系结果，实际上就是对系统的分析过程，（我认为这句话很关键，在我读这句话之前，我其实不是很清楚，软件体系结构到底是个什么意思）3大规模复用，系统体系结构的模型时一个紧凑的、易于管理的描述，描述系统如何组织和组件间如何交互，体系结构能在具有相似需求的系统之间互用，由此来支持大规模的软件复用。
体系结构设计是设计一个系统组成来满足功能性和非功能性系统需求。由于它是一个创造性的过程，所以工程中的活动很大程度上依赖于索要开发的系统类型、系统架构师的背景和经验以及系统的特殊需求。所以，把体系结构设计看作一些列将要做的决策要比把它视为一连串的活动更有效。
我在看书的时候，通过总结和归纳体系结构架构师必须做的事情，我认为系统架构有几个很重要需要考虑的问题，一个是对于索要设计的系统，是否存在一个一般性的应用体系结构可以当做模板，二一个是系统将如何分配到多个核或处理器上，三是那些体系结构模式和风格可能会用到，四个是哪种方法是系统结构分析的基本方法，五一个是如何将系统中的结构组件分解为子组件，六一个是应该使用怎么样的策略来控制系统中组件的操作，七是什么样的体系结构组织方式对于交付非功能性系统需求是最好的，八十如何评估体系结构设计，九十如何对系统体系结构文档化。
需要注意的是同一个应用领域中的系统通常具有相似的体系结构，能够反应基本的领域概念，第二是，对于嵌入式系统和为个人计算机设计的系统，一般来说只有一个处理器，不需要设计分布式体系结构。软件系统的体系机构要基于特定的体系结构模式或风格，有一句话很重要：体系结构模式是系统组成的描述。
由于非功能性需求和软件体系结构的密切关系，我们为系统所选择的特殊的体系结构风格和结构应当依赖于非功能性系统需求：性能是非功能性需求的一种，也是非功能性需求关键性的一种，那么体系结构的设计就要定位在少数几个组件上的关键操作上，把这些组件都不熟到同一台计算机而不是分配到网络中。我认为这很重要，还要考虑运行时系统组织方式，允许系统在不同的处理器上被复制和执行，我看到这里，我认为，对于某些大型企业所用的erp系统是不是就是基于这种理念产生的呢，这里我想打一个问号，希望之后的学习能够解答这个问题。
第二点是非功能性需求的信息安全性，如果信息安全性是一个关键性需求，那么体系结构的设计就要采用分层结构，把重要资源防在内层，并且在每层中采用更加严格的信息安全有效性验证。
其后关于安全性，可用性，可维护性，目前在我看来，只要记住相关概念就可以了。
对体系结构设计的评估是困难的，这是因为，对体系结构真正的检验是要看它正在使用的时候能在多大程度上满足功能性和非功能性需求，然而，在某些情况下，我们可以通过将自己的设计和参考体系结构或一般体系结构模式进行比较来评估。这段话的意思，我认为是在说，对于单个体系结构设计评估是很难的，那么就需要多方面和自己参考一般结构来做比较评估。
体系结构视图主要是描述两个问题，一个是论证视图种类的有效性，还有就是视图种类对于相关体系结构设计的契合度问题。视图的基本选择有最基本四种通过用例和脚本关联在一起的视图，分别是逻辑视图、进程视图、开发视图、物理视图。当然概念视图也不可或缺，在大多数情况下，在设计过程中就会形成概念视图。需要注意的是ADL并不能实际有效的运用，主要还是由于它的专业性。
体系结构模式是一种对号的实践所做的格式化的抽象描述，需要注意的是，文中提到MVC模式在许多基于Web的系统中，是交互管理的基础。
一些比较常用的体系结构模式：1分层体系结构，2容器体系结构3客户机-服务器体系结构，管道和过滤器体系结构、应用体系结构，（应用体系结构一般是作为某些商业和机构的需要所产生的系统）
但是，关于软件体系结构与之前的系统建模之间的关系有一些疑问，以及在手写笔记做好记录，这是关于概念性的东西没有搞清楚，很麻烦。做着重符号。

第七章

这一章主要是讲运用统一建模语言进行面向对象的软件设计，强调重要的实现问题，理解一般的面向对象设计过程中最重要的活动，理解用于记录面向对象设计的一些不同的建模，知道设计模式的思想，以及如何将其用于设计知识和经验的复用，了解实现软件时需要考虑的关键因素，包括软件复用和开源开发。

软件设计和实现是软件工程过程中的一个阶段，在这个阶段开发出可执行的软件系统。对简单的系统来说，软件设计和实现就是软件工程的全部，其他的所有活动都融汇到这个过程中，我的理解是，软件设计和实现作为软件工程过程中很重要的步骤，那么对于相对简单的系统，设计和实现基本就涵盖了所有的行为，所以，设计和实现至关重要特别是对于小型系统来讲。
软件设计和实现活动总是交叉进行的，可以基于交付方的需求识别系统组件极其关系。实现就是将之前的系统设计转变为程序的过程，设计和实现是紧密相连的，因此我们通常需要在设计的过程中考虑到实现的因素，这里我关注到，Python是一种动态语言，虽然是一个小细节，希望之后能够记到，另外需要注意的，软件项目早期，可能会出现购买现成的商业现货系统以达到减轻开发成本的目的，相对于常规的编程语言开发的方法，开发速度会更快，但是，采用这种方式开发应用程序时，设计过程要几种考虑如何配置这些功能，使得系统可以满足所有需求，通常不需要为系统做设计模型，如系统对象以及其交互的模型。
这里我觉得需要关注的地方是COTS表示可以直接购买现成系统的商业现货系统。面向对象系统是由一组相互交互的对象组成，这些对象维护它们自己的局部状态并对这些状态提供操作，面向对象的系统比起用功能方法开发出来的系统更容易改变，对象中包含数据以及处理这些数据的操作，因此它们可以被当做一个独立的实体去理解和修改，变更对象的实现或者往对象中添加服务不应该影响系统中其他的系统对象，因为对象与真实事物相关，因此，在真实世界终的实体，和系统中的控制对象之间存在清晰的映射，这里的映射我把它理解为对于上述行为或者控制的一种反应，也不知道对不对，留一个疑问，之后再看是否结论正确。
之后是关于由概念设计转变为详细的面向对象的设计需要完成几点问题，第一是了解并定义上下文和与系统的外部交互，第二是设计系统体系结构，第三是识别出系统中的主要对象，第四是开发设计模型，第五是定义对象接口，我对于这个第五点定义对象接口，不是很理解其本身含义，我理解成为，类似于一种连接状态或者说连接方式，需要注意的是，上面几种活动在实施中是相互交织和影响的，并不是相互独立不相关。
下面一个分类小节是关于系统上下文与交互的，任何软件设计过程第一阶段都是去了解待开发软件和外部环境之间存在的关系，必须要做出决策，来确定如何提供系统所需要的功能以及如何构成系统便于它能有效地与环境进行通信，了解上下文对系统边界的建立有所帮助，个在上面系统建模里面我仔细看了一下，到这里又提到一次加深了一些记忆，系统上下文模型时一个结构模型，描述开发中的系统所处环境中的其他系统，交互模型时一个动态模型，表明系统运行中是如何与环境交互的，下面就举出几个示例来方便理解，这几个例子，我把它们写在了笔记本里面，方便之后理解意思。同时系统上下文模型可以用关联来表示，关联可以简单地表示出关联所涉及 的实体之间存在的关系，下面是一个思维导图，用来描述上下文模型用关联来表示的时候所呈现的形式，这里又再一次讲到了关于用例的使用方法，不需要全部列出来，只需要概括性的归类即可，重复记忆了一下，这些用例中每一个都应用结构化的自然语言来描述，这有助于设计者识别系统中的对象和理解系统的意图。这一点很重要。
体系结构的设计是一旦完成软件系统与系统所在环境间交互的定义，就可以将这些信息作为系统体系结构设计的基础，关于对象识别，是在设计过程的这个阶段之前，随着对设计的理解逐步加深，可以精炼这些关于系统对象的想法，用例描述有助于识别系统中队形以及其操作，有时候，需要一个高层系统对象或若干用来封装用例中所定义的系统交互的对象，经过分析这些对象，就可以进行识别这些系统中的对象类了。其中比较重要的几个要点就是要，1对要构造的系统的自然羽然描述做文法分析，2使用应用领域中的真是实体，3使用基于脚本的分析识别出系统使用的各个脚本，并依次对其进行分析，实际过程中，必须综合使用许多知识来发现和归纳对象类，对于气象站的图示描述可以，比较清晰的阐述上述观点，打下着重符号，后面还会再看这个以加深理解。
关于设计模型这一小节，首先是关于其的概念以及定义，主要是：表示系统中包含的对象或对象类，同时也描述了实体间的关联与关系，这些模型时系统需求和系统实现之间的桥梁，要首先对模型进行抽象，设计模型必须为程序员提供 充分的希捷以便做出实现决策，为了避免这种情况，可以在不同细节层次开发不同的模型，同时，运动UML进行设计时候，需要结构模型和动态模型，这两种，分别是通过系统对象类以及其之间的关系来描述系统的静态结构，在这一阶段需要记录的重要关系有泛化关系，使用或者被使用关系和组成关系，另外一种是描述系统的动态结构和系统对象之间的交互，需要记录的交互包括有对象发出的服务请求序列以及由这些对象交互出发的状态变化。
在设计过程早期可以运用子系统模型，时序模型，状态模型帮助用例和体系结构增加细节。通常动态模型可以用时序图来表示。
下一小节是关于接口描述的，对涉及中不同组件之间的接口的描述是设计过程的一个重要部分，需要详细给出接口描述，以便对象和子系统能并行设计，一旦接口已经定义清楚，其他对象的开发人员就可以假设这个接口已经实现，这里回答了我上面关于接口问题的疑问，很好，我感觉这样挺有成就感的，需要注意的是，对象和接口之间不是简单的一对一的关系，相同的对象会有若干接口，每一个都是它所提供的方法上的一个视点。关于设计模式，是对问题和解决反感的基本呢绒的描述，所以该解决反感可以在不同的设置下复用，模式不是一个详细描述，可以理解为经验的描述，设计模式通常和面向对象设计相关，现有的模式通常依赖于对象的特性。设计模式有四种主要元素，1名字2问题域的描述，我的理解是问题的范围，3对部分设计的解决方案描述，描述设计方案的各个部分以及其间的关系和职责，4结果描述，说明应用该模式的结果和副作用，模式是一个很好的方法，但是需要知道每个模式适用的情况，因此要在软件设计中不断积累经验。

在实现问题中有几个很重要的点，1复用，2配置管理，3宿主机-目标机开发，但是这里关于复用的介绍我不是很明白，只知道运用在1抽象层2对象层以及组件层4系统层，这个需要后面的学习辅助理解，打一个问号，需要解决这个问题。配置管理是指管理变更中软件系统的一般过程，需要注意的是，变更和配置管理在专业化软件工程中有重要地位。这里又一个重点，就是软件开发平台应该提供的工具，1集成编译器和句法导向的编辑系统2编程语言调试系统3图形编辑工具，4测试工具5项目支持工具。对于分布式系统来说，需要决定组件部署在哪种特定平台上需要考虑组建的软硬件需求，2系统的可用性需求，3组件通信，后面还提到，如果是部署在嵌入式系统要考虑其他因素。
开源开发是软件开发的一种方法，它是将软件系统的源代码公布出来，并允许支援开发人员加入到开发过程中来，这个让我想到了安卓手机操作系统，应该就是用的这种理念，这里介绍了一些比较出名的开源产品，例如Linux Java Apache 和mySQL，需要注意的是，如果需要文档和支持，就需要给钱，对于开源公司有两个问题要考量，一个是待开发产品是否应该使用开源组件，一个是软件开发过程是否应该采用开源方法，虽然目前有很多公司采用开源的方法开发软件，因为可以降低成本，但是，很多公司认为会泄露商业机密，并且很多开源系统都是平台软件，但是开源有开源许可，通常会有3种通用模型，1GNU通用公共许可，2GNU宽松的通用公共许可，3Berkley标准分布，总得来说这一章更多是介绍类的文字类信息，需要记忆的东西很多，查阅相关专业术语很多。