软件平台设计,软件平台设计方案

实验室软件平台设计

界面可以用VB做,用shell函数就能启动对应程序

什么是软件设计？

软件设计出现的较早。由于早期程序变得越来越大，那么模块化程序，让不同的开发人员相互配合就形成了一个主题。多个程序员之间要遵从一定的规范进行编程，然后相互调用，最终使用各个模块进行组合。这种最早的形式也伴随着新的面向过程语言的出现。

软件设计的原始目的是非常简单的，就是我们要去理解一个完成的功能（软件的雏形），然后把不同的功能分化成细节的模块，然后使用一个团队进行协同开发。在这个设计活动中又找出了诸多的开发方法论（如面向过程，面向对象及现在的面向切片等等），同时也发现了诸多开发的模型（如瀑布模型，原型模型，极限编程及敏捷开发等等）。进而形成一个涉及到管理、设计等方面的细化工作，形成统一的软件工程学。同时对于软件设计也相当细化和规范（如算法、时空代价——占用空间及占用运算时间的代价）。所以现在基本上软件设计就是根据系统分师所指派的横块内进行细分（更小的模块），不同的方法论下，不同的开发模型下将功能块分为更细致的小模块（如面向对象的类，结构等）完成更细致的功能。

基本上来说，软件设计与程序设计被混为一谈，狭义的软件设计指就是程序设计，重点在于算法上的设计；广义上的软件设计其实就是对系统进行的设计，要考虑到将来软件的部署及要部署的硬件（包括软件方面与硬件方面）。也就是说，程序员不管是在算法设计上还是程序设计上都是称自己软件设计，而系统分师也在设计整个系统也称为软件设计。这是由于习惯的问题而出现的两种理解——系统设计师与分析师设计的是整个软件系统，涉及内容巨大，从部署到软件性能功能移植性等各个方面的考虑，其目的就是构造一个当前适用并具有一定前瞻性、扩展性的软件系统来支撑整个或大部分公司运行的系统。他们再把系统细分为子系统以对应公司或系统中某个相对独立的系统功能。软件设计师把自身分派到的子系统任务再进行细分，实现不同的层与模块的调用（子系统可以理解为可以相互配合的一个完整的某个方面的功能），其目的就是将理解系统进而设计为可以开发的或进行开发准备的工作；而高程与程序员则对模块功能进行分析，然后进入到开发，开发出相应的功能模块。他们所谓的软件设计设计模块内调用层次（如分层开发等），设计算法与程序以达到指定的功能要求或非功能要求。

所以软件设计在不同的范围内有不同的理解，出现这种混淆的原因也是由于软件规模的差别——让你构造一个系统时考虑的内容与构造一个工具软件所考虑的内容显然是不同的。而有些需求是一个公司的整个系统或子系统，而有些只是让你开发一个工具或一个简单的网站而已。所以各层次对于软件设计的理解也不尽相同。

基于上来说软件设计从大角度出发，其目的就是把理解变为可编程的文档。或者可以认为包括在需求分析之内的。也正是因为如此，虽然我们把软件设计挂在嘴上，但软件工程的流程中其实并不包括名词的严格定义。

软件工程中，我们按需求分析阶段、设计阶段、开发编程阶段与部署维护四个大的阶段。需求分析阶段包含可行性分析，需求采集，需求分析（包含功能需求与非功能需求）几个过程，设计阶段包含概要设计、详细设计几个过程，而编码开发阶段就编码、测试（包含单元测试，集成测试等），而部署方面包含部署、验证、维护、迁移等各个过程，事实上对于软件设计的这个不太好的定义规避掉了。所以软件设计方面的广义已逐渐被软件程所取代。

信息系统平台设计是指？

新型信息系统平台的架构

新型信息系统平台的架构自下而上共分为四层：核心数据层、应用支撑层、应用层和门户层。

图1 新型信息系统平台架构

核心数据层是以联邦数据库系统为核心，同时包括各专业应用系统数据库。联邦数据库系统实现存储和管理多数据源及异构型数据，实现数据存贮、分析与数据挖掘功能，专业应用系统数据库，包括现有已经建设完成的专业应用系统的数据库，如教学管理系统、多媒体应用系统、财务管理系统等，是多源数据的来源。实际设计时采用IBM的DB2做为联邦数据库系统，DB2支持“封装器”体系结构，它使程序员能够定制联邦 DBMS 以访问他们选定的数据源。IBM 为 DB2 提供了各种现成的封装器，使其联邦 DBMS 能够与许多关系和非关系数据源接口。关系数据源包括 DB2 系列的所有成员、Microsoft® SQL Server、Oracle、Sybase 和 Informix®。应用支撑层基于核心数据层集成、整合和管理信息，提炼出更有价值的数据，以业务视图的方式提供给应用层里的应用使用，同时应用支撑层提供身份认证、用户管理和信息加密等安全支撑；应用支撑层以web应用服务器为软件开发平台，通过支持中间件技术实现在应用系统和数据库系统之间建立应用接口，使得应用系统能够实现跨系统、跨平台地调用、整合异构的数据源。系统采用IBM 的 WebSphere Application Server，支持包括 Java Server Pages™（JSP）、Java servlet、EJB 和 Web 服务等业务逻辑编程。在此联邦 DBMS 服务器和web应用服务器体系结构中，web应用服务器通过JDBC 应用程序连接到联邦 DB2 服务器，该联邦数据库服务器被配置成访问位于不同平台上的多个数据源。这使得 JDBC 应用程序能够透明地使用任何或所有这些数据源。应用层基于应用支撑层提供的业务视图实现综合应用，应用层无须考虑底层异构信息源的复杂性，仅需专注于应用的流程和展现。门户层以校园门户网站做为与用户交互的平台。

3 两个关键技术

（1）联邦数据库技术联邦 DBMS 就是一种虚拟数据库服务器，它提供了用来访问多个数据源的单一应用程序编程接口（API）。这些数据源可能运行在不同的硬件和操作系统平台上，可能是由不同的供应商开发的，也可能使用不同的 API（包括不同的 SQL“方言”）。联邦 DBMS 技术，在 20 世纪 90 年代以商业化形式出现，给程序员提供了完全不同的数据在单一地点的印象。程序员连接到一个由联邦 DBMS 维护的虚拟数据库，并使用它的 API 去访问可能由其它地方的多种数据源所管理或生成的数据。联邦 DBMS 在幕后工作，使得对于这种完全不同的数据的访问透明且有效。这些工作包括自动数据变换、API 转换、功能补偿和数据访问操作的优化。

联邦数据库的特点：透明性联邦系统是透明的，表现在它对用户掩盖了底层数据源的差异、特质和实现。一个优异的联邦数据库对用户来说要实现位置透明、调用透明、语言透明等：即用户无需知道数据存储在哪里；无需知道数据源支持何种语言或编程接口；如果使用 SQL，无需知道数据源支持哪种 SQL 语言。异构性异构性是指各数据源之间的差异程度。数据源在许多方面可以不同。它们可以运行在不同的硬件上，可以使用不同的网络协议，以及使用不同的软件来管理它们的数据存储。它们可能具有不同的查询语言、不同的查询能力甚至不同的数据模型。它们处理错误的方式可能不同，或者提供不同的事务语义。例如一个数据源来自一个功能强大的关系数据库，另一个源于一个简单的结构化平面文件；一个可以采用 URL 形式查询并且可以根据一些 DTD 来发回半结构化的 XML 的网站，一个 Web 服务和一个响应特定函数调用集的应用程序。联邦数据库可以容纳所有这些差异，将上述这些系统封装在一个无缝的透明联邦体中。联邦体的可扩展性和开放性所有系统都需要随时间而发展。在联邦系统内，可能需要新的数据源来满足用户业务不断变化的需求。联邦数据库引擎通过称为包装器的软件组件来访问数据源。通过为那个数据源获得或创建包装器来访问新型的数据源。包装器体系结构支持新包装器的创建。一旦存在包装器之后，简单的数据定义（DDL）语句允许在不停止正在进行的查询或事务的情况下动态地将数据源添加到联邦体。数据源的自治通常，数据源有现有的应用程序和用户。所以，当将数据源引入联邦体时，不影响它的操作是很重要的。联邦数据库不影响现有数据源的本地操作，现有应用程序的运行不会发生变化，既不会修改数据也不会移动数据，接口也保持相同。尽管对联邦系统执行全局查询可能会涉及各种数据源，但数据源处理数据请求的方式并不受此影响。同样，当数据源进入或离开联邦体时，不会影响本地系统的一致性。（2）Web 应用程序服务器技术应用支撑层是以Web 应用程序服务器为基础，通过构建在中间层 Web 应用程序服务器上运行的中间件来实现其数据访问例程，Web 应用程序服务器有助于管理和部署服务器端的业务逻辑。这种逻辑（通常是用 Java 编写的）对于支持多层因特网、内部网与外部网应用程序, 可以使用不同的技术来实现这种逻辑。这些技术包括 EJB、servlet 和 Java Server Pages™（JSP）、Web 服务。实际应用中采用的WebSphere 应用服务器，WebSphere 应用服务器将Web 应用程序划分为三种类型的部件:视图类，即HTML 网页，下载到浏览器，处理用户输入和输出显示；控制器类，即Java Servlet，负责接收客户端请求，提交服务，和将结果生成HTML网页; 模式类，包括会话跟踪，用户环境信息和其它连接数据库和 IBMconnectors 的服务，提供后台信息和执行后台应用程序功能。 WebSphere应用服务器根据业界标准的Java服务器页面(JSP)提供了服务器脚本。根据不同的环境变量、JavaBean属性文件条目，以及包含这些条目的简单表达式，JSP页面可以自行生成和使用包含简单“填空”功能的动态页面。这一应用模型的好处是避免了CGI和ASP的缺点，并具有以下特点：对于客户端，大大简单了应用实施 , 浏览器不需要支持 Java，所有的Java ，或者说业务逻辑在服务器端执行，客户机下载的全部是HTML, 无需下载Java 类文件，节省了网络消耗并提高了执行速度。对于服务器端，提供中间的应用服务，并可根据性能和业务量的要求，控制运行机器的数量和大小。由于全部基于Java 服务器的技术，使得系统的移植性，可扩展性不受任何限制。 WebSphere包含了一个处理器，可以将脚本页面动态编译成JavaServlet，然后由Web应用程序服务器执行。Java Servlet和JSP 的结合，可将网页内容生成(业务逻辑) 和内容显示(HTML编排) 分离开，使得被调用的servlet 将处理信息放到一个Bean中，然后交给JSP，JSP接收到信息Bean，生成客户端的HTML。

软件系统设计需要哪些流程步骤

软件阶段：

1、问题的定义及规划

此阶段是软件开发与需求放共同讨论，主要确定软件的开发目标及其可行性。

2、需求分析

在确定软件开发可行性的情况下，对软件需要实现的各个功能进行详细需求分析。需求分析阶段是一个很重要的阶段，这一阶段做的好，将为整个软件项目的开发打下良好的基础。“唯一不变的是变化本身”，同样软件需求也是在软件爱你开发过程中不断变化和深入的，因此，必须定制需求变更计划来应付这种变化，以保护整个项目的正常进行。

3、软件设计

此阶段中偶要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计、数据库设计等。软件设计一般分为总体设计和详细设计。还的软件设计将为软件程序编写打下良好的基础。

4、程序编码

此阶段是将软件设计的结果转化为计算机可运行的程序代码。在程序编码中必定要制定统一、符合标准的编写规范。以保证程序的可读性、易维护性。提高程序的运行效率。

5、软件测试

在软件设计完成之后要进行严密的测试，一发现软件在整个软件设计过程中存在的问题并加以纠正。整个测试阶段分为单元测试、组装测试、系统测试三个阶段进行。测试方法主要有白盒测试和黑盒测试。

怎样进行软件设计

我只会弄一些小软件说点自己的看法吧首先要擅长一门语言 C C++ JAVA 都行然后用个好的开发平台傻瓜式操作最重要的是又个思路软件用来干嘛需要哪些功能能不能用熟悉的方法实现然后多跟别人交流就好了建议多做实际的软件应用能力提升很快的

什么是”软件设计”

面向对象技术，特别是C++，似乎给软件界带来了不小的震动。出现了大量的论文和书籍去描述如何应用这项新技术。总的来说，那些关于面向对象技术是否只是一个骗局的问题已经被那些关于如何付出最小的努力即可获得收益的问题所替代。面向对象技术出现已经有一段时间了，但是这种爆炸式的流行却似乎有点不寻常。人们为何会突然关注它呢？对于这个问题，人们给出了各种各样的解释。事实上，很可能就没有单一的原因。也许，把多种因素的结合起来才能最终取得突破，并且这项工作正在进展之中。尽管如此，在软件革命的这个最新阶段中，C++本身看起来似乎成为了一个主要因素。同样，对于这个问题，很可能也存在很多种理由，不过我想从一个稍微不同的视角给出一个答案：C++之所以变得流行，是因为它使软件设计变得更容易的同时，也使编程变得更容易。

虽然这个解释好像有点奇特，但是它却是深思熟虑的结果。在这篇论文中，我就是想要关注一下编程和程序设计之间的关系。近10年来，我一直觉得整个软件行业都没有觉察到做出一个软件设计和什么是真正的软件设计之间的一个微妙的不同点。只要看到了这一点，我认为我们就可以从C++增长的流行趋势中，学到关于如何才能成为更好的软件工程师的意义深远的知识。这个知识就是，编程不是构建软件，而是设计软件。

几年前，我参见了一个讨论会，其中讨论到软件开发是否是一门工程学科的问题。虽然我不记得了讨论结果，但是我却记得它是如何促使我认识到：软件业已经做出了一些错误的和硬件工程的比较，而忽视了一些绝对正确的对比。其实，我认为我们不是软件工程师，因为我们没有认识到什么才是真正的软件设计。现在，我对这一点更是确信无疑。

任何工程活动的最终目标都是某些类型的文档。当设计工作完成时，设计文档就被转交给制造团队。该团队是一个和设计团队完全不同的群体，并且其技能也和设计团队完全不同。如果设计文档正确地描绘了一个完整的设计，那么制造团队就可以着手构建产品。事实上，他们可以着手构建该产品的许多实物，完全无需设计者的任何进一步的介入。在按照我的理解方式审查了软件开发的生命周期后，我得出一个结论：实际上满足工程设计标准的惟一软件文档，就是源代码清单。

对于这个观点，人们进行了很多的争论，无论是赞成的还是反对的都足以写成无数的论文。本文假定最终的源代码就是真正的软件设计，然后仔细研究了该假定带来的一些结果。我可能无法证明这个观点是正确的，但是我希望证明：它确实解释了软件行业中一些已经观察到的事实，包括C++的流行。

在把代码看作是软件设计所带来的结果中，有一个结果完全盖过了所有其他的结果。它非常重要并且非常明显，也正因为如此，对于大多数软件机构来说，它完全是一个盲点。这个结果就是：软件的构建是廉价的。它根本就不具有昂贵的资格；它非常的廉价，几乎就是免费的。如果源代码是软件设计，那么实际的软件构建就是由编译器和连接器完成的。我们常常把编译和连接一个完整的软件系统的过程称为“进行一次构建”。在软件构建设备上所进行的主要投资是很少的——实际需要的只有一台计算机、一个编辑器、一个编译器以及一个连接器。一旦具有了一个构建环境，那么实际的软件构建只需花费少许的时间。编译50 000行的C++程序也许会花费很长的时间，但是构建一个具有和50 000行C++程序同样设计复杂性的硬件系统要花费多长的时间呢？

把源代码看作是软件设计的另外一个结果是，软件设计相对易于创作，至少在机械意义上如此。通常，编写（也就是设计）一个具有代表性的软件模块（50至100行代码）只需花费几天的时间（对它进行完全的调试是另外一个议题，稍后会对它进行更多的讨论）。我很想问一下，是否还有任何其他的学科可以在如此短的时间内，产生出和软件具有同样复杂性的设计来，不过，首先我们必须要弄清出如何来度量和比较复杂性。然而，有一点是明显的，那就是软件设计可以极为迅速地变得非常庞大。

假设软件设计相对易于创作，并且在本质上构建起来也没有什么代价，一个不令人吃惊的发现是，软件设计往往是难以置信的庞大和复杂。这看起来似乎很明显，但是问题的重要性却常常被忽视。学校中的项目通常具有数千行的代码。具有10 000行代码（设计）的软件产品被它们的设计者丢弃的情况也是有的。我们早就不再关注于简单的软件。典型的商业软件的设计都是由数十万行代码组成的。许多软件设计达到了上百万行代码。另外，软件设计几乎总是在不断地演化。虽然当前的设计可能只有几千行代码，但是在产品的生命期中，实际上可能要编写许多倍的代码。

尽管确实存在一些硬件设计，它们看起来似乎和软件设计一样复杂，但是请注意两个有关现代硬件的事实。第一，复杂的硬件工程成果未必总是没有错误的，在这一点上，它不存在像软件那样让我们相信的评判标准。多数的微处理器在发售时都具有一些逻辑错误：桥梁坍塌，大坝破裂，飞机失事以及数以千计的汽车和其他消费品被召回——所有的这些我们都记忆犹新，所有的这些都是设计错误的结果。第二，复杂的硬件设计具有与之对应的复杂、昂贵的构建阶段。结果，制造这种系统所需的能力限制了真正能够生产复杂硬件设计公司的数目。对于软件来说，没有这种限制。目前，已经有数以百计的软件机构和数以千计的非常复杂的软件系统存在，并且数量以及复杂性每天都在增长。这意味着软件行业不可能通过仿效硬件开发者找到针对自身问题的解决办法。倘若一定要说出有什么相同之处的话，那就是，当CAD和CAM可以做到帮助硬件设计者创建越来越复杂的设计时，硬件工程才会变得和软件开发越来越像。

设计软件是一种管理复杂性的活动。复杂性存在于软件设计本身之中，存在于公司的软件机构之中，也存在于整个软件行业之中。软件设计和系统设计非常相似。它可以跨越多种技术并且常常涉及多个学科分支。软件的规格说明往往不固定、经常快速变化，这种变化常常在正进行软件设计时发生。同样，软件开发团队也往往不固定，常常在设计过程的中间发生变化。在许多方面，软件都要比硬件更像复杂的社会或者有机系统。所有这些都使得软件设计成为了一个困难的并且易出错的过程。虽然所有这些都不是创造性的想法，但是在软件工程革命开始将近30年后的今天，和其他工程行业相比，软件开发看起来仍然像是一种未受过训练（undisciplined）的技艺。

一般的看法认为，当真正的工程师完成了一个设计，不管该设计有多么复杂，他们都非常确信该设计是可以工作的。他们也非常确信该设计可以使用公认的技术建造出来。为了做到这一点，硬件工程师花费了大量的时间去验证和改进他们的设计。例如，请考虑一个桥梁设计。在这样一个设计实际建造之前，工程师会进行结构分析——他们建立计算机模型并进行仿真，他们建立比例模型并在风洞中或者用其他一些方法进行测试。简而言之，在建造前，设计者会使用他们能够想到的一切方法来证实设计是正确的。对于一架新型客机的设计来说，情况甚至更加严重；必须要构建出和原物同尺寸的原型，并且必须要进行飞行测试来验证设计中的种种预计。

对于大多数人来说，软件中明显不存在和硬件设计同样严格的工程。然而，如果我们把源代码看做是设计，那么就会发现软件工程师实际上对他们的设计做了大量的验证和改进。软件工程师不把这称为工程，而称它为测试和调试。大多数人不把测试和调试看作是真正的“工程”——在软件行业中肯定没有被看作是。造成这种看法的原因，更多的是因为软件行业拒绝把代码看作设计，而不是任何实际的工程差别。事实上，试验模型、原型以及电路试验板已经成为其他工程学科公认的组成部分。软件设计者之所以不具有或者没有使用更多的正规方法来验证他们的设计，是因为软件构建周期的简单经济规律。

第一个启示：仅仅构建设计并测试它比做任何其他事情要廉价一些，也简单一些。我们不关心做了多少次构建——这些构建在时间方面的代价几乎为零，并且如果我们丢弃了构建，那么它所使用的资源完全可以重新利用。请注意，测试并非仅仅是让当前的设计正确，它也是改进设计的过程的一部分。复杂系统的硬件工程师常常建立模型（或者，至少他们把设计用计算机图形直观地表现出来）。这就使得他们获得了对于设计的一种“感觉”，而仅仅去检查设计是不可能获得这种感觉的。对于软件来说，构建这样一个模型既不可能也无必要。我们仅仅构建产品本身。即使正规的软件验证可以和编译器一样自动进行，我们还是会去进行构建/测试循环。因此，正规的验证对于软件行业来说从来没有太多的实际意义。

这就是现今软件开发过程的现实。数量不断增长的人和机构正在创建着更加复杂的软件设计。这些设计会被先用某些编程语言编写出来，然后通过构建/测试循环进行验证和改进。过程易于出错，并且不是特别的严格。相当多的软件开发人员并不想相信这就是过程的运作方式，也正因为这一点，使问题变得更加复杂。

当前大多数的软件过程都试图把软件设计的不同阶段分离到不同的类别中。必须要在顶层的设计完成并且冻结后，才能开始编码。测试和调试只对清除建造错误是必要的。程序员处在中间位置，他们是软件行业的建造工人。许多人认为，如果我们可以让程序员不再进行“随意的编码（hacking）”并且按照交给他们的设计去进行构建（还要在过程中，犯更少的错误），那么软件开发就可以变得成熟，从而成为一门真正的工程学科。但是，只要过程忽视了工程和经济学事实，这就不可能发生。

例如，任何一个现代行业都无法忍受在其制造过程中出现超过100%的返工率。如果一个建造工人常常不能在第一次就构建正确，那么不久他就会失业。但是在软件业中，即使最小的一块代码，在测试和调试期间，也很可能会被修正或者完全重写。在一个创造性的过程中（比如：设计），我们认可这种改进不是制造过程的一部分。没有人会期望工程师第一次就创建出完美的设计。即使她做到了，仍然必须让它经受改进过程，目的就是为了证明它是完美的。

即使我们从日本的管理方法中没有学到任何东西，我们也应该知道由于在过程中犯错误而去责备工人是无益于提高生产率的。我们不应该不断地强迫软件开发去符合不正确的过程模型，相反，我们需要去改进过程，使之有助于而不是阻碍产生更好的软件。这就是“软件工程”的石蕊测试。工程是关于你如何实施过程的，而不是关于是否需要一个CAD系统来产生最终的设计文档。

关于软件开发有一个压倒性的问题，那就是一切都是设计过程的一部分。编码是设计，测试和调试是设计的一部分，并且我们通常认为的设计仍然是设计的一部分。虽然软件构建起来很廉价，但是设计起来却是难以置信的昂贵。软件非常的复杂，具有众多不同方面的设计内容以及它们所导致的设计考虑。问题在于，所有不同方面的内容是相互关连的（就像硬件工程中的一样）。我们希望顶层设计者可以忽视模块算法设计的细节。同样，我们希望程序员在设计模块内部算法时不必考虑顶层设计问题。糟糕的是，一个设计层面中的问题侵入到了其他层面之中。对于整个软件系统的成功来说，为一个特定模块选择算法可能和任何一个更高层次的设计问题同样重要。在软件设计的不同方面内容中，不存在重要性的等级。最低层模块中的一个不正确设计可能和最高层中的错误一样致命。软件设计必须在所有的方面都是完整和正确的，否则，构建于该设计基础之上的所有软件都会是错误的。

为了管理复杂性，软件被分层设计。当程序员在考虑一个模块的详细设计时，可能还有数以百计的其他模块以及数以千计的细节，他不可能同时顾及。例如，在软件设计中，有一些重要方面的内容不是完全属于数据结构和算法的范畴。在理想情况下，程序员不应该在设计代码时还得去考虑设计的这些其他方面的内容。

但是，设计并不是以这种方式工作的，并且原因也开始变得明朗。软件设计只有在其被编写和测试后才算完成。测试是设计验证和改进过程的基础部分。高层结构的设计不是完整的软件设计；它只是细节设计的一个结构框架。在严格地验证高层设计方面，我们的能力是非常有限的。详细设计最终会对高层设计造成的影响至少和其他的因素一样多（或者应该允许这种影响）。对设计的各个方面进行改进，是一个应该贯穿整个设计周期的过程。如果设计的任何一个方面内容被冻结在改进过程之外，那么对于最终设计将会是糟糕的或者甚至无法工作这一点，就不会觉得奇怪了。

如果高层的软件设计可以成为一个更加严格的工程过程，那该有多好呀，但是软件系统的真实情况不是严格的。软件非常的复杂，它依赖于太多的其他东西。或许，某些硬件没有按照设计者认为的那样工作，或者一个库例程具有一个文档中没有说明的限制。每一个软件项目迟早都会遇到这些种类的问题。这些种类的问题会在测试期间被发现（如果我们的测试工作做得好的话），之所以如此是因为没有办法在早期就发现它们。当它们被发现时，就迫使对设计进行更改。如果我们幸运，那么对设计的更改是局部的。时常，更改会波及到整个软件设计中的一些重要部分（莫非定律）。当受到影响的设计的一部分由于某种原因不能更改时，那么为了能够适应影响，设计的其他部分就必须得遭到破坏。这通常导致的结果就是管理者所认为的“随意编码”，但是这就是软件开发的现实。

例如，在我最近工作的一个项目中，发现了模块A的内部结构和另一个模块B之间的一个时序依赖关系。糟糕的是，模块A的内部结构隐藏在一个抽象体的后面，而该抽象体不允许以任何方法把对模块B的调用合入到它的正确调用序列中。当问题被发现时，当然已经错过了更改A的抽象体的时机。正如所料，所发生的就是把一个日益增长的复杂的“修正”集应用到A的内部设计上。在我们还没有安装完版本1时，就普遍感觉到设计正在衰退。每一个新的修正很可能都会破坏一些老的修正。这是一个正规的软件开发项目。最后，我和我的同事决定对设计进行更改，但是为了得到管理层的同意，我们不得不自愿无偿加班。

在任何一般规模的软件项目中，肯定会出现像这样的问题，尽管人们使用了各种方法来防止它的出现，但是仍然会忽视一些重要的细节。这就是工艺和工程之间的区别。如果经验可以把我们引向正确的方向，这就是工艺。如果经验只会把我们带入未知的领域，然后我们必须使用一开始所使用的方法并通过一个受控的改进过程把它变得更好，这就是工程。

我们来看一下只是作为其中很小一点的内容，所有的程序员都知道，在编码之后而不是之前编写软件设计文档会产生更加准确的文档。现在，原因是显而易见的。用代码来表现的最终设计是惟一一个在构建/测试循环期间被改进的东西。在这个循环期间，初始设计保持不变的可能性和模块的数量以及项目中程序员的数量成反比。它很快就会变得毫无价值。

在软件工程中，我们非常需要在各个层次都优秀的设计。我们特别需要优秀的顶层设计。初期的设计越好，详细设计就会越容易。设计者应该使用任何可以提供帮助的东西。结构图表、Booch 图、状态表、PDL等等——如果它能够提供帮助，就去使用它。但是，我们必须记住，这些工具和符号都不是软件设计。最后，我们必须创建真正的软件设计，并且是使用某种编程语言完成的。因此，当我们得出设计时，我们不应该害怕对它们进行编码。在必要时，我们必须应该乐于去改进它们。

至今，还没有任何设计符号可以同时适用于顶层设计和详细设计。设计最终会表现为以某种编程语言编写的代码。这意味着在详细设计可以开始前，顶层设计符号必须被转换成目标编程语言。这个转换步骤耗费时间并且会引入错误。程序员常常是对需求进行回顾并且重新进行顶层设计，然后根据它们的实际去进行编码，而不是从一个可能没有和所选择的编程语言完全映射的符号进行转换。这同样也是软件开发的部分现实情况。

也许，如果让设计者本人来编写初始代码，而不是后来让其他人去转换语言无关的设计，就会更好一些。我们所需要的是一个适用于各个层次设计的统一符号。换句话说，我们需要一种编程语言，它同样也适用于捕获高层的设计概念。C＋＋正好可以满足这个要求。C++是一门适用于真实项目的编程语言，同时它也是一个非常具有表达力的软件设计语言。C++允许我们直接表达关于设计组件的高层信息。这样，就可以更容易地进行设计，并且以后可以更容易地改进设计。由于它具有更强大的类型检查机制，所以也有助于检测到设计中的错误。这就产生了一个更加健壮的设计，实际上也是一个更好的工程化设计。

最后，软件设计必须要用某种编程语言表现出来，然后通过一个构建/测试循环对其进行验证和改进。除此之外的任何其他主张都完全没有用。请考虑一下都有哪些软件开发工具和技术得以流行。结构化编程在它的时代被认为是创造性的技术。Pascal使之变得流行，从而自己也变得流行。面向对象设计是新的流行技术，而C++是它的核心。现在，请考虑一下那些没有成效的东西。CASE工具，流行吗？是的；通用吗？不是。结构图表怎么样？情况也一样。同样地，还有Warner-Orr图、Booch图、对象图以及你能想起的一切。每一个都有自己的强项，以及惟一的一个根本弱点——它不是真正的软件设计。事实上，惟一一个可以被普遍认可的软件设计符号是PDL，而它看起来像什么呢？

这表明，在软件业的共同潜意识中本能地知道，编程技术，特别是实际开发所使用的编程语言的改进和软件行业中任何其他东西相比，具有压倒性的重要性。这还表明，程序员关心的是设计。当出现更加具有表达力的编程语言时，软件开发者就会使用它们。

同样，请考虑一下软件开发过程是如何变化的。从前，我们使用瀑布式过程。现在，我们谈论的是螺旋式开发和快速原型。虽然这种技术常常被认为可以“消除风险”以及“缩短产品的交付时间”，但是它们事实上也只是为了在软件的生命周期中更早地开始编码。这是好事。这使得构建/测试循环可以更早地开始对设计进行验证和改进。这同样也意味着，顶层软件设计者很有可能也会去进行详细设计。

正如上面所表明的，工程更多的是关于如何去实施过程的，而不是关于最终产品看起来的像什么。处在软件行业中的我们，已经接近工程师的标准，但是我们需要一些认知上的改变。编程和构建/测试循环是工程软件过程的中心。我们需要以像这样的方式去管理它们。构建/测试循环的经济规律，再加上软件系统几乎可以表现任何东西的事实，就使得我们完全不可能找出一种通用的方法来验证软件设计。我们可以改善这个过程，但是我们不能脱离它。

最后一点：任何工程设计项目的目标是一些文档产品。显然，实际设计的文档是最重要的，但是它们并非惟一要产生的文档。最终，会期望某些人来使用软件。同样，系统很可能也需要后续的修改和增强。这意味着，和硬件项目一样，辅助文档对于软件项目具有同样的重要性。虽然暂时忽略了用户手册、安装指南以及其他一些和设计过程没有直接联系的文档，但是仍然有两个重要的需求需要使用辅助设计文档来解决。

辅助文档的第一个用途是从问题空间中捕获重要的信息，这些信息是不能直接在设计中使用的。软件设计需要创造一些软件概念来对问题空间中的概念进行建模。这个过程需要我们得出一个对问题空间中概念的理解。通常，这个理解中会包含一些最后不会被直接建模到软件空间中的信息，但是这些信息却仍然有助于设计者确定什么是本质概念以及如何最好地对它们建模。这些信息应该被记录在某处，以防以后要去更改模型。

对辅助文档的第二个重要需要是对设计的某些方面的内容进行记录，而这些方面的内容是难以直接从设计本身中提取的。它们既可以是高层方面的内容，也可以是低层方面内容。对于这些方面内容中的许多来说，图形是最好的描述方式。这就使得它们难以作为注释包含在代码中。这并不是说要用图形化的软件设计符号代替编程语言。这和用一些文本描述来对硬件科目的图形化设计文档进行补充没有什么区别。

决不要忘记，是源代码决定了实际设计的真实样子，而不是辅助文档。在理想情况下，可以使用软件工具对源代码进行后期处理并产生出辅助文档。对于这一点，我们可能期望过高了。次一点的情况是，程序员（或者技术方面的编写者）可以使用一些工具从源代码中提取出一些特定的信息，然后可以把这些信息以其他一些方式文档化。毫无疑问，手工对这种文档保持更新是困难的。这是另外一个支持需要更具表达力的编程语言的理由。同样，这也是一个支持使这种辅助文档保持最小并且尽可能在项目晚期才使之变成正式的理由。同样，我们可以使用一些好的工具；不然的话，我们就得求助于铅笔、纸以及黑板。

总结如下：

 实际的软件运行于计算机之中。它是存储在某种磁介质中的0和1的序列。它不是使用C++语言（或者其他任何编程语言）编写的程序。

 程序清单是代表软件设计的文档。实际上把软件设计构建出来的是编译器和连接器。

 构建实际软件设计的廉价程度是令人难以置信的，并且它始终随着计算机速度的加快而变得更加廉价。

 设计实际软件的昂贵程度是令人难以置信的，之所以如此，是因为软件的复杂性是令人难以置信的，并且软件项目的几乎所有步骤都是设计过程的一部分。

 编程是一种设计活动——好的软件设计过程认可这一点，并且在编码显得有意义时，就会毫不犹豫的去编码。

 编码要比我们所认为的更频繁地显现出它的意义。通常，在代码中表现设计的过程会揭示出一些疏漏以及额外的设计需要。这发生的越早，设计就会越好。

 因为软件构建起来非常廉价，所以正规的工程验证方法在实际的软件开发中没有多大用处。仅仅建造设计并测试它要比试图去证明它更简单、更廉价。

 测试和调试是设计活动——对于软件来说，它们就相当于其他工程学科中的设计验证和改进过程。好的软件设计过程认可这一点，并且不会试图去减少这些步骤。

 还有一些其他的设计活动——称它们为高层设计、模块设计、结构设计、构架设计或者诸如此类的东西。好的软件设计过程认可这一点，并且慎重地包含这些步骤。

 所有的设计活动都是相互影响的。好的软件设计过程认可这一点，并且当不同的设计步骤显示出有必要时，它会允许设计改变，有时甚至是根本上的改变，

 许多不同的软件设计符号可能是有用的——它们可以作为辅助文档以及工具来帮助简化设计过程。它们不是软件设计。

 软件开发仍然还是一门工艺，而不是一个工程学科。主要是因为缺乏验证和改善设计的关键过程中所需的严格性。

 最后，软件开发的真正进步依赖于编程技术的进步，而这又意味着编程语言的进步。C++就是这样的一个进步。它已经取得了爆炸式的流行，因为它是一门直接支持更好的软件设计的主流编程语言。

 C++在正确的方向上迈出了一步，但是还需要更大的进步。

发表于 @ 2006年12月15日 15:05:00|评论(0)|编辑

什么是软件设计

软件设计

软件设计即“…the process of applying various techniques and principles for the purpose of defining a device, a process or a system in sufficient detail to permit its physical realization. ”“ … 应用各种各样的技术和原理，并用它们足够详细的定义一个设备、一个程序或系统的物理实现的过程。 ”

对任意的工程产品或系统，开发阶段绝对的第一步是确定将来所要构建的制造原型或实体表现的目标构思。这个步骤是由多方面的直觉与判断力来共同决定的。这些方面包括构建类似模型的经验、一组引领模型发展的原则、一套启动质量评价的标准、以及重复修改直至设计最后定型的过程本身。计算机软件设计与其他工程学科相比还处在幼年时期，仍在不断变化中，例如更新的方法、更好的算法分析、以及理解力的显著进化。软件设计的方法论的出现也只有三十年多一点，仍然缺乏深度、适应性和定量性质，通常更多的与经典工程设计学科相联系。尽管如此，现今的软件技术已经存在、设计质量的标准也可使用、设计符号亦可以应用。带着这些意见，我们一起来看看什么有助于程序员们找到他们的软件涅盘 ( 天堂的意思 ) 。

什么是软件开发平台？

软件开发平台是一种软件开发工具，以通用技术架构（如MVC）为基础，集成常用建模工具、二次开发包、基础解决方案等而成。可以大幅缩减编码率，使开发者有更多时间关注客户需求，在项目的需求、设计、开发、测试、部署、维护等各个阶段均可提供强大的支持。

软件开发平台源于繁琐的实践开发过程中。开发人员在实践中将常用的函数、类、抽象、接口等进行总结、封装，成为了可以重复使用的“中间件”，而随着“中间件”的成熟和通用，功能更强大、更能满足企业级客户需求的——软件开平台应运而生。平台是一段时间内科研成果的汇聚，也是阶段性平台期的标志，为行业进入新的研发领域提供了基础。由于平台对企业核心竞争力的提升非常明显，目前国内的管理软件市场，软件开发平台的应用已经成为一种趋势。

目前国内的软件开发平台，除国际品牌如IBM，国内平台商比较成熟的有普元开发平台（代码型开发平台）、天纵智能开平台（配置型开发平台）等，部分管理软件企业也开始借力平台提升企业竞争力，如用友。

软件开发平台相对传统开发模式的优势：

1、优化产品基础架构，提升软件开发质量；

2、减少编码率，提高开发效率，提升开发的灵活性；

3、可以充分关注客户需求，实现按需定制；

4、实现配置组件的标准化，提升产品稳定性和兼容性；

5、提升企业开发能力，降低后期维护的时间和成本。

软件界面的设计要素都是什么

界面设计是为了满足软件专业化标准化的需求而产生的对软件的使用界面进行美化优化规范化的设计分支。具体包括软件启动封面设计，软件框架设计，按钮设计，面板设计，菜单设计，标签设计，图标设计，滚动条及状态栏设计，安装过程设计，包装及商品化。

在设计的过程中有较多注意的关键问题，方标邮件系统列出以下几点：

(1)软件启动封面设计

应使软件启动封面最终为高清晰度的图像，如软件启动封面需在不同的平台、操作系统上使用将考虑转换不同的格式，并且对选用的色彩不宜超过256色，最好为 216色安全色。软件启动封面大小多为主流显示器分辨率的1/6大。如果是系列软件将考虑整体设计的统一和延续性。在上面应该醒目的标注制作或支持的公司标志、产品商标，软件名称，版本号，网址，版权声明，序列号等信息，以树立软件形象，方便使用者或购买者在软件启动的时候得到提示。插图宜使用具有独立版权的，象征性强的，识别性高的，视觉传达效果好的图形，若使用摄影也应该进行数位处理，以形成该软件的个性化特征。

(2)软件框架设计

软件的框架设计就复杂得多，因为涉及软件的使用功能，应该对该软件产品的程序和使用比较了解，这就需要设计师有一定的软件跟进经验，能够快速的学习软件产品，并且在和软件产品的程序开发员及程序使用对象进行共同沟通，以设计出友好的，独特的，符合程序开发原则的软件框架。软件框架设计应该简洁明快，尽量少用无谓的装饰，应该考虑节省屏幕空间，各种分辨率的大小，缩放时的状态和原则，并且为将来设计的按钮，菜单，标签，滚动条及状态栏预留位置。设计中将整体色彩组合进行合理搭配，将软件商标放在显著位置，主菜单应放在左边或上边，滚动条放在右边，状态栏放在下边，以符合视觉流程和用户使用心理。

(3)软件按钮设计

软件按钮设计应该具有交互性，即应该有3到6种状态效果：点击时状态；鼠标放在上面但未点击的状态；点击前鼠标未放在上面时的状态；点击后鼠标未放在上面时的状态；不能点击时状态；独立自动变化的状态。按钮应具备简洁的图示效果，应能够让使用者产生功能关联反应，群组内按钮应该风格统一，功能差异大的按钮应该有所区别。

(4)软件面板设计

软件面板设计应该具有缩放功能，面板应该对功能区间划分清晰，应该和对话框，弹出框等风格匹配，尽量节省空间，切换方便。

(5)菜单设计

菜单设计一般有选中状态和未选中状态，左边应为名称，右边应为快捷键，如果有下级菜单应该有下级箭头符号，不同功能区间应该用线条分割。

(6)标签设计

标签设计应该注意转角部分的变化，状态可参考按钮。

(7)图标设计

图标设计色彩不宜超过64色，大小为16×16、32×32两种，图标设计是方寸艺术，应该加以着重考虑视觉冲击力，它需要在很小的范围表现出软件的内涵，所以很多图标设计师在设计图标时使用简单的颜色，利用眼睛对色彩和网点的空间混合效果，做出了许多精彩图标。

(8)滚动条及状态栏设计

滚动条主要是为了对区域性空间的固定大小中内容量的变换进行设计，应该有上下箭头，滚动标等，有些还有翻页标。状态栏是为了对软件当前状态的显示和提示。

(9)安装过程设计

安装过程设计主要是将软件安装的过程进行美化，包括对软件功能进行图示化。

(10)包装及商品化

最后软件产品的包装应该考虑保护好软件产品，功能的宣传融合于美观中，可以印刷部分产品介绍，产品界面

方标邮件系统企业邮件

www.foundir.com

电话:51669977

软件设计的基本步骤是什么

软件开发是指一个软件项目的开发，如市场调查，需求分析，可行性分析，初步设计，详细设计，形成文档，建立初步模型，编写详细代码，测试修改，发布等。

软件是怎么样开发出来的

第一个步骤是市场调研，技术和市场要结合才能体现最大价值。

第二个步骤是需求分析，这个阶段需要出三样东西，用户视图，数据词典和用户操作手册。

用户视图是该软件用户（包括终端用户和管理用户）所能看到的页面样式，这里面包含了很多操作方面的流程和条件。

数据词典是指明数据逻辑关系并加以整理的东东，完成了数据词典，数据库的设计就完成了一半多。

用户操作手册是指明了操作流程的说明书。

请注意，用户操作流程和用户视图是由需求决定的，因此应该在软件设计之前完成，完成这些，就为程序研发提供了约束和准绳，很遗憾太多公司都不是这样做的，因果颠倒，顺序不分，开发工作和实际需求往往因此产生隔阂脱节的现象。

需求分析，除了以上工作，笔者以为作为项目设计者应当完整的做出项目的性能需求说明书，因为往往性能需求只有懂技术的人才可能理解，这就需要技术专家和需求方（客户或公司市场部门）能够有真正的沟通和了解。

第三个步骤是概要设计，将系统功能模块初步划分，并给出合理的研发流程和资源要求。

作为快速原型设计方法，完成概要设计就可以进入编码阶段了，通常采用这种方法是因为涉及的研发任务属于新领域，技术主管人员一上来无法给出明确的详细设计说明书，但是并不是说详细设计说明书不重要，事实上快速原型法在完成原型代码后，根据评测结果和经验教训的总结，还要重新进行详细设计的步骤。

第四个步骤是详细设计，这是考验技术专家设计思维的重要关卡，详细设计说明书应当把具体的模块以最’干净’的方式(黑箱结构）提供给编码者，使得系统整体模块化达到最大；一份好的详细设计说明书，可以使编码的复杂性减低到最低，实际上，严格的讲详细设计说明书应当把每个函数的每个参数的定义都精精细细的提供出来，从需求分析到概要设计到完成详细设计说明书，一个软件项目就应当说完成了一半了。换言之，一个大型软件系统在完成了一半的时候，其实还没有开始一行代码工作。

那些把作软件的程序员简单理解为写代码的，就从根子上犯了错误了。

第五个步骤是编码，在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/ 2，通常在1/3的时间，所谓磨刀不误砍柴功，设计过程完成的好，编码效率就会极大提高，编码时不同模块之间的进度协调和协作是最需要小心的，也许一个小模块的问题就可能影响了整体进度，让很多程序员因此被迫停下工作等待，这种问题在很多研发过程中都出现过。

编码时的相互沟通和应急的解决手段都是相当重要的，对于程序员而言，bug永远存在，你必须永远面对这个问题，大名鼎鼎的微软，可曾有连续三个月不发补丁的时候吗？从来没有！

第六个步骤是测试

测试有很多种：

按照测试执行方，可以分为内部测试和外部测试

按照测试范围，可以分为模块测试和整体联调

按照测试条件，可以分为正常操作情况测试和异常情况测试

按照测试的输入范围，可以分为全覆盖测试和抽样测试

以上都很好理解，不再解释。

总之，测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，因为永远都会又不可预料的问题存在。

完成测试后，完成验收并完成最后的一些帮助文档，整体项目才算告一段落，当然日后少不了升级，修补等等工作，只要不是想通过一锤子买卖骗钱，就要不停的跟踪软件的运营状况并持续修补升级，直到这个软件被彻底淘汰为止。

什么是软件开发的核心问题

按照软件工程鼻祖，《人月神话》作者 Brooks 在“没有银弹——软件工程中的根本和次要问题”一章中阐述的思想，软件开发的核心问题就是如何从概念上对一个复杂的业务系统进行建模。这个建模是含义广泛的，不仅仅包括对象建模，还包括数据建模、算法建模等等一系列的内容。总而言之是要先找到解决复杂问题的突破口（先要搞明白需要做什么，然后再考虑如何做）。至于采用什么表示方法（简单文本、UML 图、E-R 图）、采用什么高级语言、是否一定要用面向对象、使用什么开发工具都是次要的问题。

软件开发方法

软件开发方法(Software Development Method)是指软件开发过程所遵循的办法和步骤。

软件开发活动的目的是有效地得到一些工作产物，也就是一个运行的系统及其支持文档，并且满足有关的质量要求。软件开发是一种非常复杂的脑力劳动，所以经常更多讨论的是软件开发方法学，指的是规则、方法和工具的集成，既支持开发，也支持以后的演变过程(交付运行后，系统还会变化，或是为了改错，或是为了功能的增减)。

关于组成软件开发和系统演化的活动有着各种模型(参见软件生存周期，软件开发模型，软件过程)，但是典型地都包含了以下的过程或活动：分析、设计、实现、确认(测试验收)、演化(维护)。

有些软件开发方法是专门针对某一开发阶段的，属于局部性的软件开发方法。

特别是软件开发的实践表明，在开发的早期阶段多做努力，在后来的测试和维护阶段就会使费用较大地得以缩减。因此，针对分析和设计阶段的软件开发方法特别受到重视。其它阶段的方法，从程序设计发展的初期起就是研究的重点，

已经发展得比较成熟(参见程序设计，维护过程)。除了分阶段的局部性软件开发方法之外，还有覆盖开发全过程的全局性方法，尤为软件开发方法学注意的重点。

对软件开发方法的一般要求：当提出一种软件开发方法时，应该考虑许多因素，包括：

①覆盖开发全过程，并且便于在各阶段间的过渡；

②便于在开发各阶段中有关人员之间的通信；

③支持有效的解决问题的

④支持系统设计和开发的各种不同途径；