《面向对象软件工程》笔记（一）

《面向对象软件工程》笔记
第一章 软件和软件工程

1、软件的一种分类：定制软件Custom Software、通用软件Generic Software、嵌入式软件Embeded Software。
2、软件工程 定义：是在成本、时间及其他的约束条件下，通过对大型、高质量的软件系统的系统化的开发与演进，从而解决客户问题的过程。
3、软件工程中IEEE/ACM道德公约的要点：
（1）与公共利益保持一致；
（2）在符合公共利益的前提下，最大限度地满足客户与雇主的需要；
（3）按可能的最高标准开发与维护产品；
（4）进行专业决策时保持诚信与自主；
（5）在管理中体现道德意识；
（6）在符合公共利益的前提下，提升职业的诚信和信誉；
（7）同事间公平相处、相互支持；
（8）参与终身学习。
4、相关人员，4种角色：用户user、客户customer/client、开发者developer、管理人员manager。
5、软件质量的属性：
（1）可用性usability；
（2）效率efficiency；
（3）可靠性reliability；
（4）可维护性maintainability；
（5）可重用性reuseability。
外部质量属性external quality attribute
内部质量标准internal quality criteria：
（1）代码注释量；
（2）代码的复杂性：用嵌套深度、分支数量以及所使用的复杂程序结构来衡量。
6、软件工程项目 分类：
（1）进化型项目（它又分：纠错性corrective项目、适应性adaptive项目、增强性enhancement项目、重建性re-engineering或完善性perfective项目）；
（2）零起点项目；
（3）在框架或已有构件的基础上构造项目。
7、软件项目中常见的活动
1）需求与规格说明
领域分析domain analysis：了解相关的背景信息，以便理解问题并做出明智的决定。
定义问题defining the problem：通过准确地确定需要解决的问题，限定系统的范围。
需求收集requirement gathering：收集所有人对该软件应该做什么的意见。
需求规格说明requirement specification：编写一系列准确的结构定义该软件应当做什么。
2）设计：如何利用现有技术实现需求的过程。
系统工程：确定哪些需求用硬件实现，哪些需求由软件实现。（嵌入式和实时系统）
架构：即软件体系结构，决定如何将软件划分成子系统。
详细设计：确定构造每个子系统的详细内容。
用户界面设计：确定用户与系统交互的详细方式。
3）建模：创建表示领域或软件的过程。
用例建模use case modelling：表示软件用户执行的一系列活动。
结构化建模structural modelling：表示领域或软件中的类和对象。
动态和行为建模dynamic and behavioural modelling：表示系统可能出现的状态、可能执行的活动以及构件之间如何交互。
4）程序设计：目标之一：使之自动化。
5）质量保证Quality Assurance
评审Review与审查Inspection：讨论需求、设计或代码是否令人满意的正式会议。
测试Testing：系统地执行软件，看其行为是否与预期相符的过程。
确认Validation与验证Verification
6）部署Deployment：发布与安装软件。
7）过程管理
软件的项目管理使软件工程的组成部分。
8、困难与风险
（1）复杂性与大量的细节；
（2）技术的不确定性；
（3）需求的不确定性；
（4）软件工程技术的不确定性；
（5）持续的变化；
（6）软件设计退化：不断地修改软件所带来的错误会使软件退化；
（7）“政治”风险。

第二章 面向对象概述
太简单，跳过。

第三章 基于重用技术进行软件开发
重用resue是成功软件开发的一个关键。
框架framework技术促进了重用。
框架：可重用的软件子系统，实现了能被许多应用程序使用的重要功能。也即实现了一般问题的通用解决方案。
客户机-服务器体系结构（C-S）
1、重用类型：
（1）重用专家经验；
（2）重用标准的设计与算法；
（3）重用类库或程序，或者重用语言和操作系统中内置的强大命令；
（4）重用框架；
（5）重用完整的应用程序。
商业成品Commercial Off-The-Shelf,COTS
粘合代码glue
2、将可重用性与重用引入软件工程
（1）鼓励重用，打破恶性循环；
（2）使发现可重用构件成为可能。
3、框架的关键原则：完成不同的但有相关性任务的应用程序往往有相似的设计－－特别是构件的交互模式往往是非常相似的。
（1）区别框架与其他种类软件子系统的关键：框架从本质上讲是不完全的incomplete。它缺少的部件叫插槽slot。应用程序开发人员用适应于特定应用程序的方式填充这些插槽，使框架适应他的需要。
（2）框架通常也有钩子hook：像插槽，不同之处在于钩子代表了应用框架时开发人员能够提供的可选功能。
（3）使用框架的开发人员不仅填充插槽合钩子，还使用框架提供的服务。
（4）框架的类型：框架可以是水平的，也可以是垂直的。水平框架提供大多数应用程序能够使用的一般功能。垂直框架也称应用框架application framework，提供一些功能来简化特殊种类应用程序的开发。
（5）垂直框架会有更完整的实现，并且可能有较少的插槽和钩子。应用程序通常只用到框架服务的一个子集。
4、面向对象框架：框架由类库组成，提供的服务集合是API，它由公有类中所有公有方法public method的集合定义。面向对象框架中的一些类应该是抽象的。为了在新的应用环境中使用框架，开发者创建具体类来扩展这些抽象类。抽象类中的抽象方法就是插槽，具体子类创建具体方法时将填充它们。
5、软件体系结构software architecture：是软件工程的一个分支，涉及如何组织与连接一系列软件模块使其能够在一起工作。
分布式系统distributed system：计算由不同的程序执行，这些程序一般运行在不同的硬件上，合作完成系统的任务。
瘦客户机thin-client系统：客户机被做得尽可能小，绝大部分工作由服务器完成。优点：容易通过网络下载客户机程序并且启动它。
胖客户机fat-client系统：绝大部分工作由服务器完成。优点：服务器可以更小或能处理更多的客户机。
客户机/服务器体系结构的优点：
（1）计算工作可以被分散到不同的机器上；
（2）客户机具有远程访问服务器的功能；
（3）客户机和服务器可以分别设计；
（4）所有数据集中保存在服务器中，这样保持数据的可靠性更容易；
（5）信息可以被多用户同时访问；
（6）相互竞争的客户机可以与同一个服务器通信。
6、设计服务器必须提供的功能：
（1）服务器必须初始化自己；
（2）为了客户机能够连接，它必须开始监听；
（3）它必须处理源自客户机的事件；
（4）它可能被要求停止监听；
（5）它必须在需要时干净地终止。
7、设计客户机时必须提供的功能：
（1）客户机必须初始化自己以便与服务器进行通信；
（2）执行一些工作：决定初始化一个到服务器的连接，向服务器发送消息；
（3）它必须处理源自服务器的事件；
（5）它必须干净地终止。
客户机－服务器天生就是并发的。这些并发一般需要使用能够并行执行的多线程控制来实现。
8、开发CS系统时的任务：
（1）客户机和服务器执行的基本工作，也就是计算、存储数据等；
（2）工作如何分配－－瘦客户机、胖客户机还是介于两者之间；
（3）为了完成主要活动，需要消息的细节，即通信协议；
（4）当客户机和服务器启动，处理连接、发送和接收消息、终止时所要发生的事情；
9、JAVA中建立连接
在两个应用程序中建立TCP/IP连接的包java.net，类socket是这个包中的核心元素，这个类封装了关于每个连接的信息。
为了交换信息，服务器和客户机都必须有Socket实例。
（1）建立连接前，服务器必须开始对一个端口进行监听。它使用ServerSocket类来做这件事，如下：
ServerSocket serversocket = new ServerSocket(port);
（2）客户机为了连接到服务器，使用如下语句来传递服务器的主机名和端口号：
Socket clientSocket = new Socket(host,port);
（3）为了使连接能被接受，服务器必须有一个线程使用嵌在循环中的如下语句对连接进行持续监听：
Socket clientSocket = serverSocket.accept();
（4）如通信发生故障，会抛出IOException异常；一旦建立了连接，信息交换就开始了。
对称（symmetric）的连接，指客户机和服务器使用同样的方式相互进行通信。
（5）都使用InputStream的实例来接收信息，使用OutputStream的实例来发送消息，实例按 如下方式创建：
output=clientSocket.getOutputStream();
input=clientSocket.getInputStream();
InputStream和OutputStream仅处理由字节组成的信息。要处理更复杂的数据，需要把它们 转换为一个字节流。Java提供了一系列的过滤器filter，可以把原始字节转换为其它形式。
如：DataOutputStream和DataInputStream允许对Java基本类型的直接传输；而 ObjectOutputStream和ObjectInputStream允许交换Java对象。
（6）为了发送对象，Java使用了串行化（serialization）的方法。通过该技术，每个对象 被ObjectOutputStream转化为二进制形式来传输，被ObjectInputStream接收到时进行重构 。大多数对象均可串行化，要求是它们是实现了java.io.Serializable接口的类。
如下方式包装二进制流：
output=new objectOutputStream(clientSocket.getOutputStream());
发送对象：
output.writeObject(msg);
为接收对象，要创建一个对象输入流：
input=new ObjectInputStream(clientSocket.getInputStream());
在一个循环中安排如下语句：
msg=input.readObject();
10、OCSF（Object Client-Server Framework）对象客户机-服务器框架
OCSF包含了三个类：一个用于实现客户机，另两个实现服务器。
（1）AbstractClient: openConnection, sendToServer, closeConnection,  connectionClosed, connectionException,connectionEstablished,  handleMessageFromServer.
（2）AbstractServer: listen, stopListening, close, sendToAllClinets,  getClientConnections, clientConnected, clientException, serverStarted,  serverStopped, listeningException, serverClosed, handleMessageFromClient.
（3）ConnectionToClient: sendToClient, close, setInfo, getInfo.

第四章 需求工程
1、领域分析：了解问题的背景，以便于用户交流并作出更明智的决策。
将领域分析的文档分为以下几个小节：
（1）引言：为领域命名，并说明进行分析的动机；
（2）术语表：描述领域中所有术语的含义；
（3）领域的基本知识：包括科学原理、业务过程、分析技术以及各种技术的工作原理；
（4）客户与用户；
（5）环境：描述使用的设备与系统；
（6）当前执行的任务和规程：制作一个列表描述各种人员工作时所进行的活动；
（7）竞争性软件：描述可以帮助用户与客户的可用软件，包括已经使用的软件和市场上销 售的软件；
（8）不同领域与机构之间的相似性：了解通用性与特殊性有助于创建出具有更好的可重用 性或更宽的销售市场的软件。
注意：不要写过多的详细信息，重复原始资料是一种浪费。领域分析应该只包含对已找到信 息的简要总结，以及帮助他人查找这些信息的参考。
没有坚实的领域分析，任何重大的软件项目都不应当进行。
2、软件项目的起始点：
（1）从头开发的新软件——零起点开发（green field development）；
（2）逐步改进一个现有的系统。
在深入分析详细需求之前，最好尽可能早地定义问题和范围。
3、需求：是关于系统将要完成什么工作的一段描述语句，它们必须经过所有相关人员的认 可，其目的是彻底地解决客户的问题。
需求的类型：
（1）功能性需求：描述系统应该做什么，即为用户或其它系统提供的服务。包括：系统中 的用户需要了解的该系统可以完成的所有事情；涉及与本系统有接口的其它系统的所有事情 ；不应该包括需求怎样实现的细节。进一步分：输入、输出、存储、计算、定时与同步。
（2）非功能性需求：是开发过程中必须遵守的约束。它们限制可以使用的资源和软件质量 的各个方面，即限制了决策的自由度。
非功能性需求最重要的事情之一就是使它们是可验证的。验证工作通常是测量系统的各个方 面，观察测量结果是否与需求相一致。
将各种非功能性需求划分为若干组：
（1）第一组：五个质量属性：可用性、效率、可靠性、可维护性、可重用性。
（2）第二组：约束了系统的环境与技术：平台、使用的技术、使用的开发过程、成本与交 付日期。
4、需求收集与分析技术
收集技术：
（1）观察；
（2）面谈；
（3）头脑风暴：是一组人员收集信息的有效方法，做法是人们围着桌子坐下来讨论一些主 题，目的是产生新的想法；
（4）原型化：原型是一段程序，它被快速地实现且仅包含一小部分完整系统预计实现的功 能，目的是使软件工程师较早地获得用户对其设计思想的反馈，从而完成需求收集。有：
    （4.1）纸面原型（paper prototype）：是该系统的一系列图片，它们被顺序地展示给 客户和用户，解释系统运行时发生的情况。优点：原型容易建立，对于并行开发较为理想。
    （4.2）快速原型化（rapid prototyping）：用编程语言建立对系统用户界面的模拟。 优点：可以快速地创建代码显示用户界面的重要部分。缺点：不适于创建复杂系统的最终版 本，效率低并且限制创建健壮灵活的设计能力。
（5）非正式用例分析（informal use case analysis）
用例分析是一种系统的方法，用来分析用户在你正在开发的系统上所能做的事情。
用例分析的第一步是确定将要使用本系统功能的用户类型，他们被称为参与者actor，每个 参与者需要使用系统做不同的事情。
5、需求文档的类型
需要生成几个需求文档，每个文档描述系统的不同部分或是不同的详细程度。使它们之间互补。
大型系统的需求文档通常是按照层次结构安排。顶级文档描述整个系统、各个子系统以及子系统之间的交互方式。还有独立的文档描述每个子系统。
确定需求文档的类型及详细程度：
（1）系统的大小；
（2）与其它系统接口的需要；
（3）目标读者；
（4）开发合同的签订；
（5）需求收集的阶段；
（6）领域与技术的经验水平；
（7）需求存在缺陷所导致的代价。
需求定义（Requirement Definition）一般指包含较少细节的高层文档。
需求规格说明（Requirement Specification）指更详细、更精确的文档。
6、需求评审
需求评审可能要经历多轮改进和反复的评审。
评审过程的最高阶段通常是召开由所有相关人员参加的正式需求评审会议。每个独立的需求

都应该仔细评审。需求应该是：
（1）效益大于开发成本；
（2）对解决当前的问题是重要的；
（3）使用清晰一致的表示方法表达；
（4）没有歧义；
（5）逻辑上一致；
（6）使系统有足够的质量；
（7）现实地对待可用资源；
（8）是可验证的；
（9）可唯一识别；
（10）不对系统设计做超前约束；
（11）文档应该足够完整；
（12）文档应该有合理的组织结构；
（13）推理应当清晰；
（14）文档应该被所有相关人员认可；
7、管理变化的需求
可预计的变化：
（1）业务过程的变化；
（2）技术变化；
（3）对问题有了更深入的理解；
8、领域和需求分析中的困难与风险
（1）对领域或实际问题缺少理解和发送误解；
（2）需求可能变化很快，导致需求“波动”；
（3）试图完成的工作太多；
（4）协调有冲突的需求可能是困难的；
（5）准确地陈述需求是困难的。