硬不硬只有我知道
asp.net 公司组织结构图
UIDesigner是腾讯用户研究与体验设计部（CDC）设计研发的一款设计类软件，打造一款可以让设计师统一平台和团队协作的平台型设计工具，经过1.0和2.0版本的经验沉淀，我们决定对3.0版本进行全新的架构设计。
开发一个软件系统，前期的架构设计承载着整个软件的设计思想和关键决策，可以说是重中之重。
根据软件架构设计思想，关注分割和交互，好的架构必须使每个关注点相互分离。
我们进行了最基本的需求分析，得出两个关注点：一是工具，二是设计绘图，关系如图1所示。
得到最基本的两个关注点后，接着将提取关键需求（包括：关键功能需求、关键质量需求和关键商业需求），根据两个关注点进行架构的细化设计。
一、关注点——工具这里我们结合UIDesigner的实际需求，提取出属于“工具”范畴的关键功能需求、关键质量需求和关键商业需求。
首先，“工具”的关键功能需求，必须包括：磁盘文件读写、异常捕捉、日志记录、安全性管理；非工具所必须，但是UIDesigner本身所要求的，包括：配置管理、缓存管理、线程服务、服务器和客户端通讯管理、国际化服务。
其次，“工具”的关键质量需求，质量需求包括开发期质量需求和运行期质量需求两部分，经过分析和权衡，UIDesigner的性能主要取决于设计绘图，而稳定性、可扩展性和可维护性才是决定“工具”本身发展的质量需求，因此，对“工具”的质量需求设计将以稳定性、可扩展性和可维护性为主。
最后，“工具”的关键商业需求，因为UIDesigner本身并没有很复杂的业务需求，因此关键商业需求是在设计流程的优化和规范上得到体现，这方面的设计已经属于高层模块和使用流程的设计，对架构的影响非常小，可以暂时性的忽略。
经过关键需求的提取，我们得到了“工具”的设计目标——可以提供通用功能（关键功能需求）的高稳定性、扩展性和维护性的客户端应用。
根据此目标，我们采取了DI(Dependency-Injection)和MVP(Model-View-Presenter)结合的架构，概念架构设计如图2所示。
【系统架构和软件架构】正交软件架构方法
果你想要制作易于设计、构建、测试及扩展的系统，正交性是一个十分关键的概念，但是，正交性的概念很少被直接讲授，而常常是你学习的各种其他方法和技术的隐含特性。
这是一个错误。
一旦你学会了直接应用正交性原则，你将发现，你制作的系统的质量立刻就得到了提高。
什么是正交性 文本框： “正交性”是从几何学中借来的术语。
如果两条直线相交成直角，它们就是正交的，比如图中的坐标轴。
用向量术语说，这两条直线互不依赖。
沿着某一条直线移动，你投影到另一条直线上的位置不变。
在计算技术中，该术语用于表示某种不相依赖性或是解耦性。
如果两个或更多事物中的一个发生变化，不会影响其他事物，这些事物就是正交的。
在设计良好的系统中，数据库代码与用户界面是正交的：你可以改动界面，而不影响数据库；更换数据库，而不用改动界面。
在我们考察正交系统的好处之前，让我们先看一看非正交系统。
非正交系统 你正乘坐直升机游览科罗拉多大峡谷，驾驶员——他显然犯了一个错误，在吃鱼，他的午餐——突然呻吟起来，晕了过去。
幸运的是，他把你留在了离地面100英尺的地方。
你推断，升降杆控制总升力，所以轻轻将其压低可以让直升机平缓降向地面。
然而，当你这样做时，却发现生活并非那么简单。
直升机的鼻子向下，开始向左盘旋下降。
突然间你发现，你驾驶的这个系统，所有的控制输入都有次级效应。
压低左手的操作杆，你需要补偿性地向后移动右手柄，并踩右踏板。
但这些改变中的每一项都会再次影响所有其他的控制。
突然间，你在用一个让人难以置信的复杂系统玩杂耍，其中每一项改变都会影响所有其他的输入。
你的工作负担异常巨大：你的手脚在不停地移动，试图平衡所有交互影响的力量。
直升机的各个控制器断然不是正交的。
正交的好处 如直升机的例子所阐明的，非正交系统的改变与控制更复杂是其固有的性质。
当任何系统的各组件互相高度依赖时，就不再有局部修正（local fix）这样的事情。
提示13 Eliminate Effects Between Unrelated Things 消除无关事物之间的影响 我们想要设计自足（self-contained）的组件：独立，具有单一、良好定义的目的（Yourdon和Constantine称之为内聚（cohesion）[YC86]）。
如果组件是相互隔离的，你就知道你能够改变其中之一，而不用担心其余组件。
只要你不改变组件的外部接口，你就可以放心：你不会造成波及整个系统的问题。
如果你编写正交的系统，你得到两个主要好处：提高生产率与降低风险。
提高生产率 l 改动得以局部化，所以开发时间和测试时间得以降低。
与编写单个的大块代码相比，编写多个相对较小的、自足的组件更为容易。
你可以设计、编写简单的组件，对其进行单元测试，然后把它们忘掉——当你增加新代码时，无须不断改动已有的代码。
l 正交的途径还能够促进复用。
如果组件具有明确而具体的、良好定义的责任，就可以用其最初的实现者未曾想象过的方式，把它们与新组件组合在一起。
l 如果你对正交的组件进行组合，生产率会有相当微妙的提高。
假定某个组件做M件事情，而另一个组件做N件事情。
如果它们是正交的，而你把它们组合在一起，结果就能做M x N件事情。
但是，如果这两个组件是非正交的，它们就会重叠，结果能做的事情就更少。
通过组合正交的组件，你的每一份努力都能得到更多的功能。
降低风险 正交的途径能降低任何开发中固有的风险。
l 有问题的代码区域被隔离开来。
如果某个模块有毛病，它不大可能把病症扩散到系统的其余部分。
要把它切掉，换成健康的新模块也更容易。
l 所得系统更健壮。
对特定区域做出小的改动与修正，你所导致的任何问题都将局限在该区域中。
l 正交系统很可能能得到更好的测试，因为设计测试、并针对其组件运行测试更容易。
l 你不会与特定的供应商、产品、或是平台紧绑在一起，因为与这些第三方组件的接口将被隔离在全部开发的较小部分中。
让我们看一看在工作中应用正交原则的几种方式。
项目团队 你是否注意到，有些项目团队很有效率，每个人都知道要做什么，并全力做出贡献，而另一些团队的成员却老是在争吵，而且好像无法避免互相妨碍？ 这常常是一个正交性问题。
如果团队的组织有许多重叠，各个成员就会对责任感到困惑。
每一次改动都需要整个团队开一次会，因为他们中的任何一个人都可能受到影响。
怎样把团队划分为责任得到了良好定义的小组，并使重叠降至最低呢？没有简单的答案。
这部分地取决于项目本身，以及你对可能变动的区域的分析。
这还取决于你可以得到的人员。
我们的偏好是从使基础设施与应用分离开始。
每个主要的基础设施组件（数据库、通信接口、中间件层，等等）有自己的子团队。
如果应用功能的划分显而易见，那就照此划分。
然后我们考察我们现有的（或计划有的）人员，并对分组进行相应的调整。
你可以对项目团队的正交性进行非正式的衡量。
只要看一看，在讨论每个所需改动时需要涉及多少人。
人数越多，团队的正交性就越差。
显然，正交的团队效率也更高（尽管如此，我们也鼓励子团队不断地相互交流）。
希望能帮到你，麻烦点击 好评，...
编写软件架构文档说明,第 1 部分： 什么是软件架构,为什么为软件...
引言 软件架构是一门学科，开始于 20 世纪 70 年代。
面对不断增加的复杂性和开发复杂实时系统的压力，作为主流系统工程和软件开发的基本构造，软件架构应运而生。
与任何其他久经考验的学科一样，软件架构在诞生之初也面临许多挑战。
软件架构表示系统的结构和行为方面。
在早期为软件架构编写文档说明时，所使用的文本和图解表达常常不足或者不够精确。
所需的是某种一致并得到充分理解的伪（或元）语言，以便将对软件架构进行表示和编写文档说明的不同方式统一起来。
在学术研究的推动下，在用于开发有效软件架构文档说明的最佳实践和指导原则方面，工程和计算机科学领域已取得了长足的发展。
在本系列中，您将了解如何编写软件架构文档说明。
了解编写文档说明的不同方面：系统上下文、体系结构概述、功能体系结构、操作体系结构和体系结构决策。
在这第一篇文章中，了解软件架构是什么，以及为该学科的不同方面编写文档说明的重要性。
回页首软件架构不同的研究人员已解释了软件架构是什么，并且他们对有关如何最好地表示软件系统的体系结构具有不同的观点。
其中没有哪一种解释是错误的；每种解释都具有自己的价值。
Bass L 等人抓住了软件架构的本质： “程序或计算系统的软件架构是该系统的结构，包括软件组件、那些组件的外部可见的属性，以及那些组件之间的关系” 。
此定义重点关注由粗粒度的构造（软件组件）所构成的体系结构，可以将这些构造看作是体系结构的构建块。
每个软件组件或体系结构构建块具有某些外部可见的属性，这是它向其他体系结构构建块公开的属性。
软件组件的内部设计和实现细节不是系统的其他部分所关心的内容，系统的其他部分只是将某个特定组件视为一个黑盒。
该黑盒具有某些所公开的属性，其他软件组件可以使用这些属性来共同实现业务或 IT 目标。
软件架构在恰当的粒度级别标识体系结构构建块。
软件架构还标识那些构建块如何彼此相关，并进行文档记录。
与软件工程相关的体系结构涉及到将单个系统分解或划分为一组可迭代地、渐进地和独立地构造的部分。
各个部分彼此具有显式的关系。
当组合在一起时，各个部分就形成了系统、企业或应用程序的体系结构。
关于体系结构与设计之间的区别，存在一些混淆。
正如 Clements P 等人 所指出的，所有体系结构都是设计，但不是所有设计都是体系结构。
需要绑定以使系统满足其功能性和非功能性需求和目标的设计本质上是体系结构。
体系结构将体系结构构建块视为黑盒，而设计则处理体系结构构建块的配置、自定义和内部工作。
体系结构将软件组件与其外部属性绑定在一起。
设计通常要比体系结构松散得多，因为它允许以更多的方式遵守组件的外部属性。
设计还考虑用于实现组件内部细节的各种方法。
软件架构可以递归地使用。
请考虑一个属于某个系统的软件架构组成部分的软件组件 （C1）。
软件架构师将该组件及其应该公开的属性、功能和非功能特性及其与其他软件组件的关系交给系统设计人员。
设计人员在分析软件组件 C1 之后，决定将该组件分解为更细粒度的组件（C11、C12 和 C13），其中每个组件提供可重用的功能，这些功能将用于实现 C1 的要求属性。
设计人员详细设计了 C11、C12、C13 及其接口。
此时，对设计人员来说，C11、C12 和 C13 是体系结构构造（或组件）；其中每个构造具有显式定义的外部接口。
对设计人员来说，C11、C12 和 C13 是软件组件 C1 的体系结构，并且这些构造需要进一步的改进和设计，以处理它们的内部实现。
通过将大型、复杂的系统划分为小型的构成部分并集中于每个部分，可以递归地使用体系结构。
体系结构使用共同满足行为和质量目标的体系结构构建块将系统绑定在一起。
参与者必须能够理解体系结构。
因此必须为体系结构编写足够的文档说明，下一个部分将对此进行讨论。
回页首编写体系结构文档说明的重要性参与者：体系结构的下游设计和实现用户。
为体系结构的定义、维护和增强功能进行投资的人。
向参与者传达您正在构建的系统蓝图的关键是为系统体系结构编写文档说明。
软件架构通过不同的视图进行表示——功能、操作、决策等等。
没有任何单一视图能够表示整个体系结构。
并非所有视图都需要表示特定企业或问题领域的系统体系结构。
架构师将确定足以表示所需软件架构范畴的视图集。
通过编写不同视图的文档说明并捕获每个部分的开发，您可以向开发团队和业务及 IT 参与者传达有关该不断发展的系统的信息。
软件架构具有一组其预期要满足的业务和工程目标。
体系结构的文档说明可以向参与者传达这些目标将如何实现。
为体系结构的各个方面编写文档说明，有助于架构师弥补用白板描述解决方案（使用框线图方法）与以对下游设计和实现团队有意义的方式表示解决方案之间众所周知的差距。
体系结构的框线图留下了大量有待解释的空间。
需要揭示的细节通常隐藏并令人混淆地固守在那些框线背后。
文档说明还可以促进创建切合实际并且可以系统开发（例如遵循标准模板）的体系结构构件。
作为一门学科，软件架构是非常成熟的。
您可以利用最佳实践和指导...
常见的软件架构有B/S架构和C/S架构,我想问问,我们常用的哪些软...
展开全部 B是浏览器，S是服务端，C是客户端。
简单讲B/S架构用户侧是使用浏览器获得服务；C/S架构用户侧需要先安装相应的软件，如手机上的各种APP、电脑上的qq等都是C/S架构。
据说，B/S架构是未来趋势，因为通用性强啊，不用像C/S架构还得windows、安卓、IOS各开发一款软件。
...
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语义模型的标志性的语言，也很难想象能在当前业务架构发挥太大影响。
但如果真如它所声称那样，广泛地改变着信息的结构。
那么对软件架构也会有深远影响。
什么是软件架构？
当你去了解一个东东的时候，第一步要做的，就应该去知道这个东东的定义，对于软件架构也是如此，经过网上查询和书籍的帮助，我大概理清了一个轮廓。
软件行业是一个热衷于制造‘名词’的行业，如果退回15年，估计没几个人知道‘软件架构’是什么，在上个世纪80年代，随着软件开发的规模不断扩大，软件开发成为一个行业，初期，随之而来的是越来越多的软件项目的失败，造成项目失败的原因很多，但主要集中在开发过程，所以软件工程应运而生，CMMI等流程标准也是一茬接着一茬的冒个不停。
在软件工程初具规模的时候，软件开发还是以数据结构+算法的形式存在，进入20世纪最后10年，随着面向对象技术、设计模式等在开发过程中的成功应用，软件架构也走进了大家的视野。
软件架构在定义上分为‘组成派’和‘决策派’两大阵营，分别描述如下：'组成派‘认为软件架构是将系统描述成计算组件及组件之间的交互。
它有两个非常明显的特点：关注架构实践的客体——软件，以软件本身作为描述对象。
分析了软件的组成，说明软件不是一个‘原子’意义上的整体，而是有不同的部分经过特定的接口进行连接组成的一个整体，这对软件开发来说很重要。
'决策派'认为软件架构包含了一系列的决策，主要包括：软件系统的组织选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和组合软件架构并不仅仅关注软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解、经济以及技术的限制和权衡等。
'决策派'有以下两个显著的特点：关注软件架构中的实体——人，以人的决策为描述对象。
归纳了软件架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能性需求的决策。
按照‘组成派’的观点，软件架构关注的是软件整体的分割和交互，之所以分割，是因为不同的部分在逻辑或物理上相对独立，通过‘分而治之’的原则进行分割可以更好的理解整个系统，把握用户的需求，但是虽然整个软件可以分割成多个模块或子系统，但是模块和子系统之间的通信和交互也是很重要的，我想按照这种观点，架构师的主要任务是将软件分割成不同的模块，并定义模块之间的接口。
按照‘决策派’的观点，软件是一个在很多限制下产生的产品，这些限制包括用户和技术两方面，用户方面包括功能需求、性能需求、硬件需求等，技术方面包括技术选择、可扩展性、可重用性、可维护性等。
我想按照这中观点，架构师的主要任务就是作出上述个各种限制作出选择或决策。
《软件架构设计》 温昱
什么是软件系统架构设计
“架构”一词最早来自建筑学，原意为建筑物设计和建造的艺术。
但是在软件工程领域，软件架构不是一个新名词，只是在早期的著作中人们将软件架构称为软件体系架构。
这就是架构的概念。
所谓架构，就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。
系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段，同时利用各种学科技术完成子系统的结构构建。
在系统架构中，由于对软件越来越深入的依赖，软件架构的任务也体现出重要的作用。
而且系统架构与软件架构是紧密联系和相互依赖的。
1997年，Eberhadrt Rechtin 与MarkW Maier 在其论著中，为计算机科学总结了系统架构方面的实践成果，从而奠定了系统科学和系统架构在计算机科学中的基石：无论何种系统架构应用领域，目的都是一样的，即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。
转载请注明出处51数据库 » 软件架构图 c2c asp.net
