软件结构设计,软件结构设计方法

什么是软件系统架构设计

架构师的职责主要有如下4条：

1、确认需求

在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。

2、系统分解

依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。

软件架构师的功力基本体现于此，这是一项相对复杂的工作。

3、技术选型

架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。

Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。

架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。

4、制定技术规格说明

架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。

架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。

软件体系结构的建模是怎样的？

一、软件体系结构和框架的定义

软件体系结构的英文单词是“architecture”. Architecture的基本词义是建筑、建筑学、建筑风格。

软件体系结构虽然根植于软件工程，但还处于一个研究发展的阶段，迄今为止还没有一个为大家所公认的定义。

《设计模式》中对框架的定义是框架就是一组相互协作的类，对于特定的一类软件，框架构成了一种可重用的设计。

软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架类型。框架的作用在于：由于提取了特定领域软件的共性部分，因此在此领域内新项目的开发过程中代码不需要从头编写，只需要在框架的基础上进行一些开发和调整便可满足要求；对于开发过程而言，这样做会提高软件的质量，降低成本，缩短开发时间，使开发越做越轻松，效益越做越好，形成一种良性循环。

框架不是现成可用的应用系统。是一个半成品，需要后来的开发人员进行二次开发，实现具体功能的应用系统。框架不是“平台”，平台概念比较模糊可以是一种操作系统，一种应用服务器，一种数据库软件，一种通讯中间件等地那个，因此平台在应用平台主要指提供特定服务的系统软件，而框架更侧重了设计，开发过程，或者可以说，框架通过调用平台提供的服务而起的作用。

框架不是工具包或者类库，调用API并不就是在使用框架开发，紧紧使用API是，开发者完成系统的主题部分，并不时地调用类库实现特定任务。而框架构成了通用的、具有一般性的系统主体部分，二次开发人员只是像做填空一样，根据具体业务，完成特定应用系统中与众不同的特殊部分。

二、框架与架构之间的关系

框架不是构架（即软件体系机构）。体系结构确定了系统整体结构、层次划分，不同部分之间的协作等设计考虑。框架比架构更具体。更偏重于技术涉嫌。确定框架后，软件体系结构也随之确定，而对于同一软件体系结构（比如Web开发中的MVC），可以通过多种框架来实现。

三、框架与设计模式之间的关系

设计模式和框架在软件设计中是两个不同的研究领域。设计模式研究的是一个设计问题的解决方法，一个模式可应用于不同的框架和被不同的语言所实现；而框架则是一个应用的体系结构，是一种或多种设计模式和代码的混合体虽然它们有所不同，但却共同致力于使人们的设计可以被重用，在思想上存在着统一性的特点，因而设计模式的思想可以在框架设计中进行应用。

框架和设计模式存在着显著的区别，主要表现在二者提供的内容和致力应用的领域。

1)从应用领域上分，框架给出的是整个应用的体系结构；而设计模式则给出了单一设计问题的解决方案，并且这个方案可在不同的应用程序或者框架中进行应用。

2)从内容上分，设计模式仅是一个单纯的设计，这个设计可被不同语言以不用方式来实现；而框架则是设计和代码的一个混合体，编程者可以用各种方式对框架进行扩展，进而形成完整的不同的应用。

3)以第二条为基础，可以得出设计模式比框架更容易移植：框架一旦设计成形，虽然还没有构成完整的一个应用，但是以其为基础进行应用的开发显然要受制于框架的实现环境；而设计模式是与语言无关的，所以可以在更广泛的异构环境中进行应用。

总之，框架是软件，而设计模式是软件的知识体，提升框架的设计水平。

Feedback

# re: 软件体系结构（构架）、架构、设计模式之间的关系回复更多评论

2005-11-18 13:08 by 非鱼

FRAMEWORK和ARCHITECTURE属于不同的设计层次。DP和FRAMEWORK、ARCHITECTURE分属不同的领域，DP只能和ARCHITECTURAL PATTERN相提并论。

# re: 软件体系结构（构架）、架构、设计模式之间的关系回复更多评论

2005-11-18 17:59 by publisher luo

ARCHITECTURE是描述系统整体的一种结构（C/S架构,B/S架构，三层架构等），使用框架开发的web系统也是一种体系结构，而架构是系统中的一部分具体实现。框架的设计也使用了很多设计模式。设计模式只是一个问题解决域，而框架可以利用设计模式来解决客观存在的问题。不知道这么说是否好理解一点。

祝你生活愉快

谢谢

开发软件项目,在软件结构设计时,必须遵循什么原则

为高质量地开发软件项目,在软件结构设计时必须遵循(信息隐蔽)的原则,(自顶向下)建立软件系统的模块结构.并且应根据(模块独立性)评价系统模块划分的质量.此外在模块设计时,应从5种基本的(控制结构)出发,利用它们组合成一个模块的程序块结构.要求每个(程序块)的结构应是单入口和单出口.

java软件开发的架构设计

软件架构作为一个概念，体现在技术和业务两个方面。

从技术角度来说：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术和一些基本原则的基础之上。

先说一些基本原则：

分层原则：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。

模块化原则：模块化是化解软件广度复杂的必然手段，模块化的目的就是让软件分工。

接口实现分离原则随着软件模块化的不断深入改进，面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块之间的耦合度，从而让各模块更轻松改进。从这个原则出发，软件也从微观进行了细致的规范化。

还有两个比较小但很重要的原则：

细节隐藏原则很显然把复杂问题简化，把难看的细节隐去，能让软件结构更清晰。其实这个原则使用很普遍，java/c++语言中的封装原则以及设计模式中的Facade(外观)模式就很能体现这个原则的精神。

依赖倒置原则随着软件结构的进一步发展,层与层之间、模块与模块之间的依赖逐渐加深，而层、模块的动态可插拔要求不端增大。依赖倒置原则可看视为接口实现分离原则的深化，根据此原则的精神，软件进入了工具时代。这个原则有点类似于知名的好莱坞法则：Don’t call us, we’ll call you。

以上这些原则奠定了我们的软件架构的价值指标。但软件架构毕竟是建立在当前技术之上的。而每一代技术都有架构模式。过去的不再说了，让我们就来看一下当前流行的技术，以及当前我们能采用的架构。

因为面向对象是当前最流行开发技术，且设计模式的大量使用使面向对象的走向成熟，而数据库是当前最有效的存储结构、web界面是当前最流行的用户接口，所以当前最典型的三层次架构就架构在以上几项技术的基础之上，用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。我们从三层次架构谈起：

因为面向对象技术和数据库技术不适配，所以在标准三层次架构的基础上，我们增加了数据持久层，来管理O-R双向映射，但目前一直没有最理想的实现技术。cmp和entity bean技术因为其实现复杂，功能前景有限，已接近被淘汰的边缘。JDO及hibernate作为o-r映射的后期之秀，尤其是hibernate，功能相当完备。推荐作为持久层的首选

在业务层，因为当前业务日趋负载，且变动频繁，所以我们必须有足够敏捷的技术来保证我们的适应变化的能力，在标准j2ee系统中session bean负责业务处理，且有不错的性能表现，但采用ejb系统对业务架构模式改变太大，且其复杂而昂贵，业务代码移植性差。而spring 作为一个bean配置的轻量级架构，漂亮的IOC模式实现，对业务架构影响小，所以推荐作为中间层业务框架。

在用户结构层,虽然servlet/jsp/jstl/javaBean 能够实现MVC架构，但终究过于粗糙。struts对MVC架构的实现就比较完美，Taperstry也极好地实现MVC架构，且采用基于事件的方式，非常诱人，惜其不够成熟，我们仍旧推荐struts作为用户接口层基础架构。

因为业务层是三层次架构中最有决定意义的，所以让我们回到业务层细致地分析一下，在复杂的业务我们常常需要以下基础服务的一种或几种：事务一致性服务acid(tool:jta/jts)、并发加锁服务concurrent&&lock、池化管理服务cache、访问控制服务(tool:jaas)、流程控制服务workflow、动态实现服务IOC，串行化消息服务(tool:jms)、负载平衡服务blance等。如果我们不采用重量级应用服务器(如weblogic,websphere,jboss等)及重量级组件(EJB)，我们必须自己实现其中一些服务。虽然我们大多情况下，不需要所有这些服务，但实现起来却非易事。幸运的是我们有大量的开源实现代码，但采用开源代码却常常是件不轻松的事。

随着xml作为结构化信息传输和存储地位日渐重要,一些xml文档操作工具(DOM,Digester,SAX等)的使用愈发重要，而随着 xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，采用xml schema来设计xml文档格式，然后采用java binding来生成java bean 会成为主要编程模式,而这又进一步使数据中心向xml转移，使在中小数据量上,愈发倾向于以xquery为查询语言的xml数据库。现还有一个趋势， microsoft,ibm等纷纷大量开发中间软件如(microsoft office之infopath)，可以直接从xml schema 生成录入页面等非常实用的功能。还有web service 的广泛应用，都将对软件的架构有非常重大的影响。至于面向服务架构(SOA)前景如何，三层次架构什么时候走入历史，现还很难定论。

aop的发展也会对软件架构有很深的影响，但在面向对象架构里，无论aspectJ还是jboss-aop抑是aspectWerks、 nanning都有其自身的严重问题：维护性很差，所以说它将很难走远。也许作为一个很好的思想，它将在web service里大展身手。

rdf,owl作为w3c语义模型的标志性的语言，也很难想象能在当前业务架构发挥太大影响。但如果真如它所声称那样，广泛地改变着信息的结构。那么对软件架构也会有深远影响。

什么是软件设计?

软件设计是一系列创造活动,是借助编程语言以简单和优雅的方式表达并解决现实需求的一门科学和艺术.- 软件设计是一门技数据结构,组成原理,操作系统,编程语言科学的特点是有规律可循,因此软件设计者需要掌握相关的专业知识.而这些科学知识通常容易被量化和评估.- 软件设计是一门艺并不是技术知识的简单堆砌,而是分析,抽象,取舍一个好的设计必然给人带来没敢,也让人值得欣赏.

设计软件系统结构的具体办法有哪些

结构化程序设计的思路是：自顶向下、逐步求精；其程序结构是按功能划分为若干个基本模块；各模块之间的关系尽可能简单，在功能上相对独立；每一模块内部均是由顺序、选择和循环三种基本结构组成；其模块化实现的具体方法是使用子程序。结构化程序设计由于采用了模块分解与功能抽象，自顶向下、分而治之的方法，从而有效地将一个较复杂的程序系统设计任务分解成许多易于控制和处理的子任务，便于开发和维护。虽然结构化程序设计方法具有很多的优点，但它仍是一种面向过程的程序设计方法，它把数据和处理数据的过程分离为相互独立的实体。当数据结构改变时，所有相关的处理过程都要进行相应的修改，每一种相对于老问题的新方法都要带来额外的开销，程序的可重用性差。由于图形用户界面的应用，程序运行由顺序运行演变为事件驱动，使得软件使用起来越来越方便，但开发起来却越来越困难，对这种软件的功能很难用过程来描述和实现，使用面向过程的方法来开发和维护都将非常困难

如何正确运用软件进行结构设计

但是 ,在实际建筑结构设计使用计算机时 ,如果不知道如何选择适合于具体结构的程序 ,不知道如何判断程序计算过程是否正确 ,那么结构设计就会变成只能听命于机器操作的“架空设计”。面对复杂的结构体系和结构分析 ,结构设计人员黑盒子作业现象愈趋严重 ,出现不问程序应用范围随意套用 ,不加分析选择计算间图、输入参数物理意义不明而任意选用、对输出结果不进行合理性分析就盲目采用等现象 ,严重影响设计质量和工程的安全 ,如不给予重视 ,则由于程序使用不当而造成工程事故的出现将是难免的。针对这一现象 ,本文就结构分析软件应用的有关问题提出一些看法 ,供大家商酌。1 程序应用中应注意的问题(1)各种结构的计算程序可以为计算提供很好的手段 ,要想得到正确的计算结果 ,并在施工图中应用 ,除了程序的准确性外 ,还与输入数据的正确性和结构简化的合理性 ,程序选用的正确性 ,都有很大的关系 ,因此必须根据工程设计经验对计算结果进行分析、判断 ,根据其正确与否作为设计的依据。