前一阵子学习面向对象软件工程,留下了印象种种,现将我自己对软件工程的一些理解写在下面,欢迎大家指正,如果诸位觉得没有什么意思,也请提出来,那我也就不再将后续的文章写出来,并发表在这里,一来以免在这里浪费了大家的版面空间,二来,也为自己多一些时间做一些其它方面的事.
　　当然,如果你是对我写的这些东西感兴趣的话,也请表示你的支持(写一下回帖,增加一下人气啦).这也是对我的一些鼓励.先谢谢啦!
　　 青海渔风
　　 2000-05-12
　　
　　第一部分 概述
　　在以前,我觉得在阅读一本技术文章时,觉得最没有兴致的就是前面的概述部分,但是,当自己想写这么一样的东西时,又发现有必要写一些概述的东西,呵呵,或许我以后会对那些概述的印象会有所改变.
　　在这一部分中,我将谈一些软件工程的一些理解,这也是我后面可能存在的文章的基础.必须注意的是,我这里并没有过多地谈论一些概念,因为那些东西在许多书中有详细的定义,无论那些定义是不是准确,但也有助于你对软件工程的理解的.
　　我所理解的软件工程,它贯穿于一个软件项目的整个生命周期,即从项目立项,需求分析,系统分析(功能分析),到详细设计,到代码编制, 直到测试然后交付使用,最后还有售后服务,其实更深一步说,此生命周期还包括本项目中的部分软件部件可以在其它项目中使用,则生命周期因此而增加.
　　我觉得现在我国做软件的时候,一般没有考虑这么远,首先有很多软件公司的软件开发队伍中根本没有软件工程的概念,二是即使有软件工程的概念,也是基于软件生命周期的前期,即认为它只存在于系统分析,和功能设计,最多到编码,而测试安装及售后服务都不是他们的考虑之列,我觉得这是我国软件发展尚没有完善的一点.我们来考虑一下,如果在系统分析时,没有考虑到将来维护的需要,而没有给将来的出错留下太多的提示信息,只是简单地报一下错,这样,在将来系统出现问题后,将会有多少麻烦的事. 而如果没有考虑到本次项目中的某些技术或部件在将来的项目中的重用性,则必然增加软件开发成本,增加软件开发期.这也是对一个软件企业的成长不利的.
　　就软件工程的作用而言,在我所看过的书籍有列有许多,我觉得最重要的一点在于它的长期效益,其实就一个项目本身而言,软件工程可能会增加成本的,这也是许多小型的软件公司不愿意进行完善的软件工程的原因.当然,这也是有道理的,在没有解决生存问题的时候,就要考虑一个五年甚至十年计划,那也太难为了一点!但是如果一个软件公司要想获得长期战略优势,或是要将其经验转化为战略优势,软件工程势在必行的.这也是为什么软件工程学在近些年在国外比较流行的原因.在国内,由于发展的滞后性,目前尚没有在企业中广泛地使用软件工程,但作为一种趋势,对于软件工程学的学术上的讨论目前正在加强,在未来的几年内,软件工程学有可能是软件企业最为关心的话题.
　　软件工程学发展到今,也已经经历了几代,同时它的发展是与开发工具的发展息息相关的.最初软件是为了效率而存在的,没有什么软件工程的概念,而这个时候的开发工具主要是汇编之类的较为原始的语言,后来发展得比较好的是以结构为基础的软件工程,包括结构化分析与结构化设计,这与当时开发工具主要是以过程和函数为主有关.而目前,面向对象的软件开发工具大行其道,而与之相关的,面向对象的软件工程也就浮出了水面.
　　与传统的软件工程(主要是结构化的)相比,面向对象的软件工程,更好的支持了前面所说的软件生命周期的后几个环节,即售后服务,特别是重用.这表现为对象比函数在将来的项目中,更具有生命力.
　　函数倾向于一种功能,在将来的项目中,实现同样的功能的方法变化会是很大的,这样,当这功能实现方法变化时,你的函数也就要重新写,再编译,连接.而对象不同,它表现为一个完整的实体,它是存储一些数据并实现一些功能的整合体.它隐藏了功能实现的具体细节.这就好比,你要建一栋房子,而用什么样的砖,你的操作方法也就不一样,这里你的操作方法也就是功能(函数或过程),而砖也就是数据,由于数据是独立于功能而存在的,它的变化,功能不能及时反映,比如别的一个模块调用了这样的一个建房子的功能,那么它就必须根据不同的砖头来判断调用哪一个建房子功能.
　　而如果你把建房子当作一个对象,那么砖(也就是其中的数据)和建房子的方法(过程)都被封装在其中了,假设这个对象提供了一个接口(建房子),别的人用这个对象时,只需要执行这个方法,而其中的细节它也就不用管了,让我们来看一下,如果砖头变化了呢?我们只要修改对象内部的实现细节,而别人在用这个对象时,依然是调用建房子这样的一个方法,它是不用知道用什么砖头的.
　　
　　好啦,这些就做为概述部分吧,也该结束了,如果概述就写了太多,就不能算是概述了.下回再说吧.

第一章 需求分析
　　１．１ 软件生命周期
　　在这一章中，我们首先来回顾一下软件生命周期，前面我已经提到过，我所认为的软件工程是
　　贯穿于一个软件生命周期中的全部。
　　与生命周期在其它范畴的意义相似，它包括一个软件的：需求分析，系统分析／系统设计，编
　　码，测试／验收，售后服务。前面也提到过，如果本次软件中运用到的技术在以后的项目中得
　　以运用，那么，这一软件的生命周期将在以后的项目中延伸。之所以要强调这一点，是因为与
　　此相对应，软件工程就需要考虑到这一生命周期的延长。
　　顺便提一下，在这一生命周期中，其与客户有接触的有需求分析，验收及售后服务。其它部分
　　一般没有用户的参与（当然，具体的项目可能有不同）。将这一点提出来，是因为如果注意到
　　这一点，就需要在这些步骤中，充分考虑客户的因素。
　　
　　１．２ 需求分析概述
　　其实，无论你用什么样的软件工程方法，需求分析都是差不多的，所以，在这一部分中，我并
　　不会特别注意面向对象这一点。但是，在软件生命周期的后续阶段，面向对象与其它软件工程
　　方法需要的数据会有一些差别，所以，在这一阶段需求分析与其它软件工程方法也是有一些差
　　别的。下面将首先说它们共通的东西。
　　需求分析是第一个与客户接触的环节，客户将根据需求分析的优劣来产生第一印象，如果做得
　　好，将为后续工作带来极大的方便，当然这一点与软件工程无关，只是随便说一点吧。
　　需求分析是了解用户需求的过程，它的结果将是以文档形式表示的客户需求。理想情况是，做
　　出了需求说明文档后，在β测试之前，都不再需要与用户进行交流。当然这只是一种理想情况
　　，再好的需求分析也不能够达到这一点，因为即使在做需求分析时，已经考虑得很充分了，但
　　是，做软件是有一个过程的，我在实际工作中碰到了这样的情况：客户单位与另外一个单位合
　　并，呵呵，可想而知，合并前的两个公司对同样的事做法是不一样的，需求当然也就有区别，
　　这时，也就难免要修改设计文档了，当然，修改文档客户是要另外给钱的，但设计文档还是得
　　改了呀！当然还有另外的一种情况，比如公司内部部门调整（目前常见的情况是：客户单位为
　　通过ISO9000系列认证而修改公司管理结构，没有办法，在这种情况下，给你钱是好的，不给钱
　　，你也得做。题外话，反正这不是什么非常专业的文档，没有关系吧？：），之所以在这里大
　　倒需求分析人员的苦水，也是要告诉那些做开发的，有时，不是需求分析人员没有做得好，有
　　时需求分析的变化是与他们无关的。而且有时，会在需求分析说明文档中留下余地，以使将来
　　可能的变化时，可以灵活一些。
　　需求分析的结果是需求分析文档。那么需求分析的结果有什么要求呢？因为需求分析联结的是
　　用户和系统分析人员，前者是没有什么技术背景的人，而后者恰好相反，没有什么业务背景。
　　系统分析的结果是要给用户确认的，而其后使用它最多的将是系统分析员。所以，做需求分析
　　，写需求分析文档是比较有难度的，它不能是技术文档，因为用户不会关心你是用什么技术实
　　现的，但也是岗位职责说明书，那不是系统分析员想知道的。要写一份让用户能够放心签字，
　　同时也要让系统分析员觉得好的文档并不太容易。
　　有这样的一个故事，说的是为什么英国的海军可以一度称霸海洋的。说原因在于它在建造军舰
　　之前，就建了一个模型，还没有开始建造，就让将来可能使用这个军舰的人站在模型旁，讨论
　　如果让他来操作，是不是合适；而让可能负责建造的人也站在模型旁，看它的设计是否符合技
　　术要求。
　　提这样的一个故事，是为了说，需求分析说明的作用与那个模型的作用一样，在软件开发之前
　　，给用户一个模型，让他考虑，就在目前这个说明文档中所描述的情况下，是否已经实现了它
　　的全部功能。而它给系统分析人员看时，就是让他们考虑，所描述的系统是不是可以实现。
　　
　　１．２ 需求分析方法
　　在实践中，需求分析方法有很多的，根据具体情况采用不同的方法，以下提供一种分类：
　　一、被动法
　　这种方法适用于一些静态的、确定的数据的收集，比如发票格式，报关单格式，入／出库单格
　　式等。用这种方法的优点是对被调查人员影响较小，同时，投入人力也较小。其缺点是不容易
　　发现一些不太显然的信息，如发票中背书内容，因为这一部分在一定工作中没有一定之规，所
　　以，容易被被调查对象忽略。而且这种方法也有很多偶然性因素，比如一个刚与人吵过架的人
　　来填写答卷与一位心平气和的人来填写答卷，就同样原调查目标，可能有不同的结果。
　　被动法主要有：问卷法，样张收集，资料整理。
　　二、主动法
　　这种方法容易发现一些容易被被调查对象漏掉的信息，比如发票的背书信息，如果你用问卷，
　　则十个人可能有十种答案，而且说法还可能不可以归类。而如果用访谈方式进行，则调查者可
　　以引导访谈对象将这些答案归类，比如可以问：你刚才所说的情况是不是与．．．类似之类的
　　提示性的话。但访谈法也是有缺点的，它的缺点是对于执行人的要求比较高，而且可能在那种
　　环境下，被访问对象可能会对一些数据漏掉，因为在访谈中，被访问对象有可能没有时间整理
　　其思路。
　　主动法主要有：开座谈会，深度访谈等。
　　
　　１．３ 面向对象软件工程对需求分析的要求
　　前面已经提到过，在需求分析阶段，是否面向对象软件工程并不太明显，但是，如果考虑到以
　　后的需要的话，在细节上可能会有一些不同，说白了，也就是考虑到以后需求说明书中的功能
　　都将是由对象实现的，可以在需求分析时，考虑一下现在的资料是不是适合由对象来实现，以
　　及如何实现，当然，这个时候的考虑也只是初步的，同时这对需求分析人员也提出了更高的要
　　求，但如果考虑到了，那就会为将来的系统分析有好处。这里我也只是提一个思路，但是，具
　　体有什么例子，我也一时也说不上，以后的例子中也许会有相应的内容出现。
　　
　　说句实话，在我的经历中所知道的需求分析，一般做得都不怎么样，如果我自己去做，或许做
　　得比他们做得还差，这是中国式企业管理造成的，最后提客观一句，只是为了说一个意思，如
　　果一个企业是封闭式生产，即生产成型的软件产品去出售，那么他的需求分析可以做得相对好
　　些，而如果是以项目为主导，即强调了客户的作用的话，那么？需求分析即使写好了，最后做
　　些改动，甚至是结构性变化都是“合理”的，没有办法呀，毕竟有些东西是写不进需求分析说
　　明文档，将其搬到桌面上来讲的。

第二章 系统分析／设计（一）
　　前面的需求分析没有什么独特的地方，这也下体现了一个系统中是稳定的东西是需求，所以，对于需求分析的方法比较成熟，没有什么太大的变化。从系统分析开始，就有很多不确定因素在其中做怪了，所以，面向对象与否，差别就已经很大了。
　　２．１ 对象的一般知识
　　既然是面向对象软件工程，那么，对象就是贯穿整个软件工程过程的。首先我们来看一下，什么是对象：对象就是存有一些数据并实现一些方法的实体。当然这也不是什么精确的定义。
　　在我的理解中，一个对象中有四样：一是数据（属性），二是动作（方法），三是事件（响应），四是消息（接口）。下面用一个简单但不是很规范的例子来说明这四个方面。我将以自行车为例：
　　如果将自行车当作一个对象，那么，数据包括元数据与对象数据，这也是组成对象的结构化信息，自行车里的数据也就是它有两个轮子，一个三角架，一个龙头等等，这些东西也可以看成是对象，例如轮子是由钢丝与轮箍组成的。
　　动作是指对象内部的一些功能，在我们的自行车对象中，动作也就是加速，减速，停车这些动作。
　　其中消息分为内部消息与外部消息，外部消息是指此对象与其它对象的关联，也就是说，对象是通过消息与其它对象通讯的；内部消息是指组成对象的各个对象之间的关联。还是以我们的自行车为例，我对于自行车来说，是一个外部对象，我用脚去脚蹬，我这个外部对象，发给了自行车一个消息，那就是外部消息。而脚蹬在接到这个外部消息后，就会带动链条移动，这样链条得到的消息相对于自行车这个对象来说，就是内部消息了。
　　而事件是对象对于消息的响应，相应的，事件也被分为内部事件与外部事件。同样以我们的自行车为例，脚蹬响应我的脚的动作，这是外部事件，而链条响应脚蹬的发过来的消息，那是内部事件。说了这么多，也差不多了，还有一点强调的是，这些内部／外部都是相对于当前对象而言的。
　　对象还可以根据这四个方面表现出来的基本特征可以分类：一是数据对象，它是以存储数据为主，不响应消息，比如销售管理系统中的发票；第二类是控制对象，它一般不保存什么数据（即使有一些数据，也只是一些状态值），只响应一个或多个消息；更多的是第三类，这类消息是存储一些数据并响应一定的消息。其中第三类的对象一般是复合对象，前两种一般表现为元对象。系统分析的结果中出现的对象必须是元对象或可以分解为元对象。
　　２．１ 系统分析／设计的一般知识
　　系统分析／设计过程，也就是发现和标识系统中的对象，并定义上面所说的四个方面的过程。在系统分析结束后，系统中的对象必须都可以分解为元对象／元数据。
　　面向对象软件工程的系统分析一般有以下几个步骤：分析资料，发现并标识对象，定义对象的结构和其它资料，在定义过程中发现子对象，再重复以上过程。这样一个不断细化的过程是不是非常熟悉呢？呵呵，对了，在面向功能的分析中，这也是常用的方法，不过，细化的对象不一样罢了。那么，在这个过程中起点是什么呢？那就是应用程序对象。
　　前面当需求分析做完之后，有一个文档化的东西，那就是需求说明文档，说实话，那样的一个文档，实在与其它面向功能／过程的方法得出来的东西没有什么两样，但是系统分析／设计得出来的东西，那与其它方法得出来的东西就完全不同了，它是一个对象定义文档，这所描述的是每一个对象的组成，功能，及相互关系。这些就是一个系统的全部。
　　下面将从如何分析文档开始进入令我激动但愿也能让你感兴趣的面向对象软件工程之系统分析／设计部分。