什么是系统架构设计

[什么是会计制度设计]《会计制度设计》在阐明会计基本理论和基本知识的基础上，重点阐明会计制度设计的内容和方法，具有较强的科学性、先进性和适用性。书名：会计制度设计作者：屈志凤出版社：天...+阅读

什么是系统架构设计

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

1、确认需求

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

2、系统分解

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

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

3、技术选型

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

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

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

4、制定技术规格说明

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

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

Android架构设计的思想与原则是什么

rlei分析了Android的设计哲学：理解好Intent，就可以理解Android哲学（所有应用生来平等）的一部分。举个简单的例子，iOS里面应用要集成SNS如facebook/twitter/sina weibo等，都需要应用自己实现（iOS5也只是集成twitter一家）；Android上只需要广播一个share内容的intent。从理解Intent如何工作开始，你就在慢慢理解Activity Manager, Package Manager, Services这些Android的重要组件是如何工作的。另外Binder是Android架构里非常核心的一块。Android基于Intent的消息传递和组件/应用解耦，下面的基础都是Binder IPC。在这一点上，Android实际上是光荣的传承了BeOS和Palm OS 6（悲催的OS6...）未能发扬光大的一部分。MVC(Content Provider, Activity, Layout, Adapters)这个比较基础，也不算Android特有的。Content Provider对数据访问的抽象也是比较有意思的一块。

理想情况下，content provider可以让客户端用URI以语义化的方式访问数据（URI本身即表示数据层次结构和查询条件），而下面数据库表的结构可以任意变动，不影响客户端代码。当然实做的时候content provider还是会被各种复杂的where子句暴露出SQL的实现细节至于Android的权限管理，其实比较简单，主要是利用现成的Linux安全模型，进程之间相互隔离。API级别的权限管理和JVM类似。Billy Cui重点解析了权限系统的设计：Android的权限系统是基于Linux，但又增加了很多自己的控制模块。总体上来说，其分为以下几部分权限系统：1. userid ：继承于linux，对于多个app，通过shareuid的方式可以使用同一个userid，主要承担一些目录访问权限之类的工作，比如私有目录只能由同一uid应用访问。2. 安装level:system level or app level，这个是根据应用的安装位置决定的，在system/app下安装的应用就是system level，在权限访问中会得到更多的权限，比如静默安装应用的权限等。

3. permission ：这个是最主要的权限控制，一般开发者开发应用主要是接触这个部分，在这部分中，会根据应用在AndroidManifest.xml中声明的use-permission而在访问相应api或资源时判断其是否有访问权限，比如常用的android.permission.INTERNET等。4. signature：签名，是Android权限系统中的重要组成部分，对于系统签名的应用，会有一些特殊的功能，而shareuid等特性也是需要同一签名作为基础。此外，permission在设置/自定义其权限时也经常会使用到签名，比如控制只有我自己的应用才可以访问我自己定义的公开API。除此以外，其实Android在uid的里面设置了一些预定义有特殊功能的uid，比如system/media等，在配置其system level的services的时候会用到。董兆辉则认为Android主要是基于组件搭配思想：说到Android架构的设计思想和原则，按我的理解主要是组件搭配，即在用户看来，所有的module或者组件，都是可以重复利用和简单组合的。

想法是好的，不过有得必有失，或者说Android现在做的还不够好，在性能方面是很低的，否则的话Android也不会推出补丁（NDK之类的，dalvik的不断升级）。我觉得所有Framework或者平台或者语言都想给应用开发者最方便使用的接口，最人性化的体验，同时又要争取最大的性能，两者权衡折中吧。不过随着硬件速度的飞速增长，性能的权重会变低。范怀宇还谈到了资源体系：Android架设在Linux之上，因此，继承了Linux可移植性、用户管理机制、文件系统，等等。Android的核心在Framework层，本质上，这是一个基于组件的应用开发系统，组件间通过消息（Intent）进行通信。一方面，Intent是通信信息的载体，另一方面，Intent也定义了Android组件的通信协议。Android可以对组件所运行的进程做托管，在Android中，进程概念相当薄弱。

依赖于进程托管，Android可以轻松支撑多任务多进程的应用模型。

主动数据库系统的结构和设计思想是什么

1.3. 数据库系统结构

从数据库管理系统的角度看，数据库系统通常采用三级模式结构。本节将介绍数据库系统的模式结构。

1.3.1. 模式的概念

模式（schema）是数据库中全体数据的逻辑结构和特征的描述，它仅仅涉及到类型的描述，而不涉及到具体的值。模式的一个具体值称为模式的一个实例（instance）。同一个模式可以有很多实例。模式是相对稳定的，实例是相对变动的，因为数据库中的数据总在不断地更新。模式反映的是数据的结构及其联系，而实例反映的是数据库某一时刻的状态。

1.3.2. 三级模式结构

数据库系统的三级模式结构是指数据库系统是由外模式、模式、内模式，这三级构成的。如图 1.4所示

图 1.4. 数据库系统的三级模式结构

模式（schema）

模式也称为逻辑模式，它是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。它是数据库系统模式结构的中间层，既不涉及数据的物理存储细节和硬件环境，也与具体的应用程序，与所使用的应用程序开发工具以及程序设计语言无关。

DBMS提供模式描述语言（模式DDL）来严格地定义模式。

外模式（external schema）

模式也称为用户模式或子模式，它是数据库用户（包括程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一特定应用有关的数据的逻辑表示。

外模式通常是模式的子集。一个数据库中可以有多个外模式。外模式是保证数据库安全性的一个有力措施，每个用户只能看见和访问到相应的外模式的数据，他看不见数据库中的其余数据。

DBMS提供外模式描述语言（外模式DDL）来严格地定义外模式。

内模式（internal schema）

模式也称为存储模式，一个数据库只能有一个内模式。它是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。

DBMS提供内模式描述语言（内模式DDL）来严格地定义内模式。

1.3.3. 两级映像与数据独立性

数据库系统的三级模式是对数据的三个抽象级别，它把数据的具体组织工作留给了DBMS管理，使用户能够从逻辑层面上处理数据，而不必关心数据在计算机中的具体表示方式和存储方式。为了能够在内部实现这三个抽象层次的联系和转换，DBMS在这个三级模式之间提供了两级映像：

外模式/模式映像

模式/内模式映像

正是这两级映像保证了数据库系统中的数据能够具有较高的逻辑独立性和物理独立性。

外模式/模式映像

模式描述的是数据的全局逻辑结构，外模式描述的是数据的局部逻辑结构。对应于同一个模式可以有任意多个外模式。对于每一个外模式，数据库系统都有一个外模式/模式的映像，它定义了该外模式与模式之间的对应关系。

当模式改变时，由数据库管理员对各个外模式/模式映像做相应的改变，就可以使外模式保持不变。应用程序是依据数据的外模式编写的，从而应用程序不必修改，保证了数据与程序的逻辑独立性，简称为数据的逻辑独立性。

模式/内模式映像

数据库中只有一个模式，也只有一个内模式，所以模式/内模式的映像是唯一的。它定义了数据库全局逻辑结构与物理存储结构之间的对应关系。

当数据库的物理存储结构改变时，由数据库管理员对模式/内模式映像做相应的改变，就可以使模式保持不变。从而应用程序也不必改变。这样就保证了程序与数据的物理独立性，简称为数据的物理独立性。

在数据库的三级模式结构中，数据库模式，即全局逻辑模式是数据库的中心与关键，它独立于数据库的其他层次。因此，设计数据库模式结构时，应首先确定数据库的逻辑模式。

什么是软件系统架构设计

软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口_（计算机科学）来实现。软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。

特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。在“软件构架简介”中，David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

在Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。一般而言，软件系统的架构（Architecture）有两个要素：它是一个软件系统从整体到部分的最高层次的划分。一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。

详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。所谓架构元素，也就是组成系统的核心＂砖瓦＂，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。