系统架构的设计方法(设计软件系统结构的具体办法)
1.设计软件系统结构的具体办法有哪些
结构化程序设计的思路是：自顶向下、逐步求精；其程序结构是按功能划分为若干个基本模块；各模块之间的关系尽可能简单，在功能上相对独立；每一模块内部均是由顺序、选择和循环三种基本结构组成；其模块化实现的具体方法是使用子程序。
结构化程序设计由于采用了模块分解与功能抽象，自顶向下、分而治之的方法，从而有效地将一个较复杂的程序系统设计任务分解成许多易于控制和处理的子任务，便于开发和维护。 虽然结构化程序设计方法具有很多的优点，但它仍是一种面向过程的程序设计方法，它把数据和处理数据的过程分离为相互独立的实体。
当数据结构改变时，所有相关的处理过程都要进行相应的修改，每一种相对于老问题的新方法都要带来额外的开销，程序的可重用性差。由于图形用户界面的应用，程序运行由顺序运行演变为事件驱动，使得软件使用起来越来越方便，但开发起来却越来越困难，对这种软件的功能很难用过程来描述和实现，使用面向过程的方法来开发和维护都将非常困难。
2.系统架构方案有哪些
系统架构属于系统设计阶段，系统架构图只是这个阶段一个产物，要正确的、合理的画系统架构图需要全面的理解用户需求以及业务流程，当理解了这些东西后，剩下的就是如何进行表达了，一般而言，可以参照RUP的用例驱动来进行逻辑架构，开发架构等设计工作，你的系统架构图可以反应在各个视图里面，我估计你所说的系统架构图是属于逻辑架构里面，比如分多少层，每层分多少模块等。
至于，绘制的工具，有很多很多。可以选择微软的visio，或者EA,rose,power designer等UML建模工具，当然，你甚至可以用PPT,Word来绘制。
当然，系统架构不是一日之功，需长期努力，跟经验和技术都有很大关系。
今天兴致来了，回复了这么多，不知满意不。
3.系统架构方案有哪些
系统架构属于系统设计阶段，系统架构图只是这个阶段一个产物，要正确的、合理的画系统架构图需要全面的理解用户需求以及业务流程，当理解了这些东西后，剩下的就是如何进行表达了，一般而言，可以参照RUP的用例驱动来进行逻辑架构，开发架构等设计工作，你的系统架构图可以反应在各个视图里面，我估计你所说的系统架构图是属于逻辑架构里面，比如分多少层，每层分多少模块等。
至于，绘制的工具，有很多很多。可以选择微软的visio，或者EA,rose,power designer等UML建模工具，当然，你甚至可以用PPT,Word来绘制。
当然，系统架构不是一日之功，需长期努力，跟经验和技术都有很大关系。 今天兴致来了，回复了这么多，不知满意不。
4.面向对象的设计中,系统架构设计的内容有哪些
面向对象程序设计中的概念主要包括：对象、类、数据抽象、继承、动态绑定、数据封装、多态性、消息传递。通过这些概念面向对象的思想得到了具体的体现。
1）对象（Object） 可以对其做事情的一些东西。一个对象有状态、行为和标识三种属性。
2）类（class） 一个共享相同结构和行为的对象的集合。
类（Class）定义了一件事物的抽象特点。通常来说，类定义了事物的属性和它可以做到的（它的行为）。举例来说，“狗”这个类会包含狗的一切基础特征，例如它的孕育、毛皮颜色和吠叫的能力。类可以为程序提供模版和结构。一个类的方法和属性被称为“成员”。
5.如何做好软件系统的架构设计
软件架构设计的目的 对于外包业务类型的项目，软件架构设计的目的与产品类型的项目有所不同，在这里主要讨论外包类型项目的软件架构设计目的。
1、为大规模开发提供基础和规范，并提供可重用的资产，软件系统的大规模开发，必须要有一定的基础和遵循一定的规范，这既是软件工程本身的要求，也是客户的要求。架构设计的过程中可以将一些公共部分抽象提取出来，形成公共类和工具类，以达到重用的目的。
2、一定程度上缩短项目的周期，利用软件架构提供的框架或重用组件，缩短项目开发的周期。 3、降低开发和维护的成本，大量的重用和抽象，可以提取出一些开发人员不用关心的公共部分，这样便可以使开发人员仅仅关注于业务逻辑的实现，从而减少了很多工作量，提高了开发效率。
4、提高产品的质量，好的软件架构设计是产品质量的保证，特别是对于客户常常提出的非功能性需求的满足。 软件架构设计的原则 软件架构设计必须遵循以下原则： 1、满足功能性需求和非功能需求。
这是一个软件系统最基本的要求，也是架构设计时应该遵循的最基本的原则。 2、实用性原则，就像每一个软件系统交付给用户使用时必须实用，能解决用户的问题一样，架构设计也必须实用，否则就会“高来高去”或“过度设计”。
3、满足复用的要求，最大程度的提高开发人员的工作效率。 软件架构设计的几种视图 我们常常在讨论架构设计该做些什么的时候，或是在架构设计评审的会议上，会提出各种各样的问题，例如开发人员该如何记录Log，事务如何控制？怎样才能提高我们的开发人员的工作效率，即在单位时间内更有品质的完成更多的功能？怎样满足客户的非功能性需求？怎样让生产环境的平台管理人员更好的维护系统？ 上面这些问题，实际上是软件系统的不同的干系人站在不同的角度上提出的问题，要回答上面这些问题，我们就得从不同的视角来看待软件架构设计这项工作。
1、逻辑架构视角，从系统用户的角度考虑问题，设计出来的软件架构能够满足业务逻辑的需求，能够处理现在越来越复杂的业务逻辑需求。 2、开发架构视角，从系统开发人员的角度来考虑问题，设计的架构要易于理解，易于开发，易于单元测试，最好做到让开发人员可以用最少的代码行数完成功能的开发。
3、运行架构视角，从系统运行时的质量需求考虑问题，特别关注于系统的非功能需求，客户常常都会要求我们系统的功能画面的最长响应时间不超过4秒，能满足2000个用户同时在线使用，基于角色的系统资源的安全控制等。 4、物理架构视角，关注系统安装和部署在什么样的环境上，例如现在最流行的企业应用服务解决方案IBM Http Server + WebSphere Application Server + DB2,WebLogic + Oracle等。
5、数据架构视角，如今我们开发的各类系统，如MIS,ERP,SAP，基本上都是对各类数据的操作，把一堆不太好懂的数据展现成用户容易看懂的数据，自动处理各类数据的运算等，所以数据的持久化是十分重要的一件事情。1、分析需求和理解业务模型（或领域建模），并选定关键Use case。
软件的需求，可以分为从用户视角和开发人员视角来看，从用户的角度看，又可以分为功能性和非功能性需求，我们必须从不同的视角和级别去全面的认识需求并分析需求，理解业务模型。实践表明，常常被我们忽视的非功能性需求常常会导致整个项目失败。
理解业务需求最好的方式莫过于进行领域建模，领域建模与需求分析往往是交替穿叉进行的，领域建模主要有以下三个方面的作用： ◆探索复杂问题，弄清领域知识。Martin Fowler曾经说过，他采用面向对象方法最大的好处就是它有助于解决更为复杂的问题。
领域建模本身作为辅助思维的工具，帮助我们将注意力始终保持在最为重要的业务概念及其关系上，使我们能够不断深入地，系统的对需求进行分析和认识。领域建模往往是一个从模糊到清晰，从零散到系统的过程。
◆决定功能范围，影响可扩展性。任何模型都是对现实世界某种程序的抽象，这种抽象就会忽略某一些东西，例如忽略对象的属性和对象间的关系，而这些忽略往往都是带有一定的目的性的，这种忽略就决定了功能的范围。
模型揭示了各种功能背后的结构，如果说定义功能相当于“拍照片”的话，那么领域建模就相当于“做透视”，更加关注问题领域的内在结构，相当于对问题领域进行了一定的抽象，良好的领域模型不仅能很好的支持现有的功能，而且还可以在一定程度上支持未来可能出现的新需求，体现良好的可扩展性。 ◆提供交流基础，促进有效沟通。
领域建模通常会使用UML图作为呈现的方式，这样为我们的沟通提供了方便。当然，有时候文字在描述某些特定领域的问题时可能更适合，可以灵活运用。
在我们公司的实际软件开发流程中，往往领域建模缺少这一环节，这可能是在以后的工作中需要进一步提高之处。 虽然我们总是期望架构设计师能全面掌握需求，但由于时间和精力的限制，摆在我们面前的现实就是架构设计师没有时间对所有需求进行深入分析，所以我们的策略就是“把好钢用在刀刃上”，即把大部分时间和精力花在对决定架构最重要的关键需求。
6.什么是系统架构设计
系统架构设计是人们对一个结构内的元素及元素间关系的一种主观映射的产物。系统架构设计是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
扩展资料：
系统架构设计师是一个最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。
系统架构设计师考试合格人员能够根据系统需求规格说明书，结合应用领域和技术发展的实际情况，考虑有关约束条件，设计正确、合理的软件架构，确保系统架构具有良好的特性；能够与系统分析师、项目管理师相互协作、配合工作；具有高级工程师的实际工作能力和业务水平。
架构师是由国外引进的一个概念，国外软件开发的几个职位是技术官、架构师、设计师、开发、测试，对应我们的公司应该是技术总监、架构师、系统分析员、程序员、测试人员。
参考资料：搜狗百科-系统架构设计
参考资料：搜狗百科-系统架构设计师
7.组织结构设计的要求与方法有哪些
组织结构设计的六项主要内容：
(1)职能设计
职能设计是指企业的经营职能和管理职能的设计。企业作为一个经营单位，要根据其战略任务设计经营、管理职能。如果企业的有些职能不合理，那就需要进行调整，对其弱化或取消。
(2)框架设计
框架设计是企业组织设计的主要部分，运用较多。其内容简单来说就是纵向的分层次、横向的分部门。其纵向和横向的一般模式可表示如下：
(3)协调设计
协调设计是指协调方式的设计。框架设计主要研究分工，有分工就必须要有协作。协调方式的设计就是研究分工的各个层次、各个部门之间如何进行合理的协调、联系、配合，以保证其高效率的配合，发挥管理系统的整体效应。
(4)规范设计
规范设计就是管理规范的设计。管理规范就是企业的规章制度，它是管理的规范和准则。结构本身设计最后要落实、体现为规章制度。管理规范保证了各个层次、部门和岗位，按照统一的要求和标准进行配合和行动。
(5)人员设计
人员设计就是管理人员的设计。企业结构本身设计和规范设计，都要以管理者为依托，并由管理者来执行。因此，按照组织设计的要求，必须进行人员设计，配备相应数量和质量的人员。
(6)激励设计
激励设计就是设计激励制度，对管理人员进行激励，其中包括正激励和负激励。正激励包括工资、福利等，负激励包括各种约束机制，也就是所谓的奖惩制度。激励制度既有利于调动管理人员的积极性，也有利于防止一些不正当和不规范的行为。
详细介绍您可以参考这里：
/view/543252.htm#6
8.简要描述系统概要设计包括哪些方面的架构
在需求明确、准备开始编码之前，要做概要设计，而详细设计可能大部分公司没有做，有做的也大部分是和编码同步进行，或者在编码之后。
因此，对大部分的公司来说，概要设计文档是唯一的设计文档，对后面的开发、测试、实施、维护工作起到关键性的影响。一、问题的提出 概要设计写什么？概要设计怎么做？如何判断设计的模块是完整的？为什么说设计阶段过于重视业务流程是个误区？以需求分析文档还是以概要设计文档来评估开发工作量、指导开发计划准确？结构化好还是面向对象好？以上问题的答案请在文章中找。
二、概要设计的目的 将软件系统需求转换为未来系统的设计；逐步开发强壮的系统构架；使设计适合于实施环境，为提高性能而进行设计；结构应该被分解为模块和库。三、概要设计的任务 制定规范：代码体系、接口规约、命名规则。
这是项目小组今后共同作战的基础，有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法，大家就有了共同的工作语言、共同的工作平台，使整个软件开发工作可以协调有序地进行。总体结构设计：功能（加工）->模块：每个功能用那些模块实现，保证每个功能都有相应的模块来实现；模块层次结构：某个角度的软件框架视图；模块间的调用关系：模块间的接口的总体描述；模块间的接口：传递的信息及其结构；处理方式设计：满足功能和性能的算法 用户界面设计；数据结构设计：详细的数据结构：表、索引、文件；算法相关逻辑数据结构及其操作；上述操作的程序模块说明（在前台？在后台？用视图？用过程？······） 接口控制表的数据结构和使用规则 其他性能设计。
四、概要设计写什么 结构化软件设计说明书结构（因篇幅有限和过时嫌疑，在此不作过多解释） 任务：目标、环境、需求、局限；总体设计：处理流程、总体结构与模块、功能与模块的关系；接口设计：总体说明外部用户、软、硬件接口；内部模块间接口（注：接口≈系统界面） 数据结构：逻辑结构、物理结构，与程序结构的关系；模块设计：每个模块“做什么”、简要说明“怎么做”（输入、输出、处理逻辑、与其它模块的接口，与其它系统或硬件的接口），处在什么逻辑位置、物理位置；运行设计：运行模块组合、控制、时间；出错设计：出错信息、处错处理；其他设计：保密、维护；OO软件设计说明书结构1 概述 系统简述、软件设计目标、参考资料、修订版本记录 这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时，对于非功能性的需求例如性能、可用性等，亦需提及。
需求规格说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能。
在随后的文档部分，将解释设计是怎么来实现这些的。2 术语表 对本文档中所使用的各种术语进行说明。
如果一些术语在需求规格说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。3 用例 此处要求系统用用例图表述（UML），对每个用例（正常处理的情况）要有中文叙述。
4 设计概述4.1 简述 这部分要求突出整个设计所采用的方法（是面向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose）4.2 系统结构设计 这部分要求提供高层系统结构（顶层系统结构、各子系统结构）的描述，使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离，对前者进行描述。
别忘了说明图中用到的俗语和符号。4.3 系统界面 各种提供给用户的界面以及外部系统在此处要予以说明。
如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据，必须在此说明。
4.4 约束和假定 描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。
另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种情况下，要求清楚地描述与本系统有交互的软件类型以及这样导致的约束。
实现的语言和平台也会对系统有约束，同样在此予以说明。对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等。
5 对象模型 提供整个系统的对象模型，如果模型过大，按照可行的标准把它划分成小块，例如可以把客户端和服务器端的对象模型分开成两个图表述。在其中应该包含所有的系统对象。
这些对象都是从理解需求后得到的。要明确哪些应该、哪些不应该被放进图中。
所有对象之间的关联必须被确定并且必须指明联系的基数。聚合和继承关系必须清楚地确定下来。
每个图必须附有简单的说明。6 对象描述 在这个部分叙述每个对象的细节，它的属性、它的方法。
在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。
