系统概要设计

我们要开发的软件已经从需求阶段过渡到系统分析、总体设计阶段（话说虽到了分析阶段，实质我们还有很多需求不确定呢~~）。所谓系统设计就是根据需求分析的结果，完成系统构建的过程。这段时间是即让人兴奋，又让我感到艰难而困惑的过程。兴奋是因为，作为软件工程的学生，终于可以用的自己的“本行”知识。艰难，是因为在做总体分析、设计的过程中遇到了很多问题，如：理论知识储备不够，根本没搞清楚该过程到底要做什么，什么是值得做的。另外进行的实质阶段的时候，发现有些软件自动化工具不会用，真是屋漏偏逢连夜雨~~

本次汇报从两个方面讲述，实践篇、收获篇。

实践篇:

我在分析的时候，是边写文档边分析的，所以遇到的第一个问题就是要搞清楚我要写什么报告，老师告诉我是进行总体设计、用户接口的设计，正好我手上一整套的国标(GB8567——88)的软件过程各个阶段的所有文档，因此，我找准了我们需要完成的是概要设计报告和用户界面设计报告。找到目标后着手开始写，但是当我看到文档的目录时（如图1）就基本发晕了，心想，原来是那么复杂哪。

图1.文档目录结构

此时联想到学过的UML，心想：UML不是涉及到软件开发的每个过程么？那我就用UML来表示了，于是赶紧安装了Rational Rose和Visio。下面我就按照文档的目录的顺序来说下我在边分析边写文档时候遇到的各种问题。

需求规定：用了用Visio作了系统的纵向功能结构图。

运行环境：当然是Windows+？？（还不知道用什么具体的技术开发呢~）。

基本设计概念：说实话，这里我不知道写什么，看了别人写的文档，也很不统一，有的人写的是在设计本身的一些概念，比如面向对象、面向过程等软件工程技术的设计概念。还有一部分就写了为什么要这样设计，这样设计的好处。还有一部分写了具体项目的一些专有名词。

处理流程：我是用用例图代替的，当初我是用的处理流程图，但是我认为跟第四部分的运行设计重复了。

结构：在我的理解中就是软件基本框架和结构。设计的时候我划分了好几个层次，从上到下依次是UI层、ControlCenter层，ModelFuntion层和Service层。

接口设计：

用户接口：用户接口是指UI，也就是界面跟用户的接口。（个人是这样认为的，也有人认为是用户需要调用的函数，我感觉应该是一样的）。UI在界面报告中设计的比较多，而且各种操作函数已经在前面的模块细节当中写的很清楚，因此这里没有仔细写。

外部接口：外部接口就是本系统同外部的硬件或软件交互的接口，很显然，本系统外部接口是指ONVIF Core Specification提供的API。

内部接口：指系统内部的接口，这个接口的设计我花了很大的力气，因为设计时，如果我用抽象层次高的接口时发现有些细节的操作可能非常麻烦，但是模块接口划分的非常细致的时候又发现软件结构就变的非常不清晰，组件的独立性不高，各种交互也非常凌乱，因此，我很难找到功能、性能、清晰性之间的平衡，后来还是认为层次结构的清晰性是最重要的，哪怕是牺牲了些性能，但是系统运行的健壮性应该可以得到保证。

数据逻辑结构的设计：每个操作都对应一个操作代码，这个操作肯定又附带了参数，然后这个操作调用过后可能会返回一些请求数据，因此，我先设计一个参操作类，操作类中有操作代码(ActionCode)、操作参数（ActionParam）、操作返回参数（ActionReplyParam）这些参数。其中，操作参数（ActionParam）、操作返回参数（ActionReplyParam）要因具体操作而定，他们都继承与操作参数（ActionParam）类，操作参数（ActionParam）类将每个功能模块分类，是每个具体操作参数类的父类，这样的抽象程度层次较清晰。在具体使用的时候可以通过工厂获得里面具体的数据项。

收获篇：

总体设计： 当我们拿到一个需求时，应该怎样开始设计呢？我本人原以为自己知道了面向对象、统一建模语言、设计模式等看似新鲜而深奥的名词就可以进行设计了，后来我才发现自己错了，即使掌握这些也不是成为优秀分析师或设计师的充分条件，甚至不是必要条件，何况我对那些知识还不是很熟悉呢？在设计时，设计角度不同，遇到了很多可能想到的方法，当我想这样设计的时候，从另外一个角度考虑又很快把当初想法的可行性给抹杀掉了，我是特别的纠结。可能总体设计就是一个舍得取舍的过程吧，我们需要的就是综合各种因素在内的平衡点。我平时还要多多积累、实践、学习。了解、掌握、消化、总结前人或自己的成果也许会是提高自己的一个好方法，我也会继续对前面的工作进行总结！

接口设计：

面向对象给我们带来的一大好处是接口与实现的分离，这使得我们在考虑程序逻辑时可以完全不用考虑程序将怎样编写，而只考虑对象交互的接口。对于设计工作来说，这既是一个挑战，也是一大优势。接口设计有很多种，有面向行为的接口设计，即把所有具有相似行为的类，抽象出来作为一个接口，这样行为就很统一。另外还有一种方法叫做基于业务的抽象，也就是我所采用的方法，也算是一种层次的抽象方法。

在这几天有关接口的学习中我还认识到有接口比没有接口好，哪怕这个对象行为与其他任何对象都不一样，完全没有抽象价值，甚至看不到将来变更的可能。极端一点来说，我们应当为每一个对象都设计接口，因为我们不知道是否这个功能的实现方式在以后是否有什么改变。

另外有些收获是软件使用上面的，如用Rational Rose画UML，用Visio画结构图等。