什么是软件系统架构设计
“架构”一词最早来自建筑学,原意为建筑物设计和建造的艺术。
但是在软件工程领域,软件架构不是一个新名词,只是在早期的著作中人们将软件架构称为软件体系架构。
这就是架构的概念。
所谓架构,就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。
系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段,同时利用各种学科技术完成子系统的结构构建。
在系统架构中,由于对软件越来越深入的依赖,软件架构的任务也体现出重要的作用。
而且系统架构与软件架构是紧密联系和相互依赖的。
1997年,Eberhadrt Rechtin 与MarkW Maier 在其论著中,为计算机科学总结了系统架构方面的实践成果,从而奠定了系统科学和系统架构在计算机科学中的基石:无论何种系统架构应用领域,目的都是一样的,即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。
什么是软件基础架构
软件架构 软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。
软件架构描述的对象是直接构成系统的抽象组件。
各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。
在面向对象领域中,组件之间的连接通常用接口_(计算机科学)来实现。
软件体系结构是构建计算机软件实践的基础。
与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念,多数工程师(尤其是经验不多的工程师)会从直觉上来认识它,但要给出精确的定义很困难。
特别是,很难明确地区分设计和构架:构架属于设计的一方面,它集中于某些具体的特征。
在“软件构架简介”中,David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。
结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。
”[GS93] 但构架不仅是结构;IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。
构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。
它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。
在 Rational Unified ProcESs 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。
一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。
软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作、逻辑和流程。
什么是软件架构?
当你去了解一个东东的时候,第一步要做的,就应该去知道这个东东的定义,对于软件架构也是如此,经过网上查询和书籍的帮助,我大概理清了一个轮廓。
软件行业是一个热衷于制造‘名词’的行业,如果退回15年,估计没几个人知道‘软件架构’是什么,在上个世纪80年代,随着软件开发的规模不断扩大,软件开发成为一个行业,初期,随之而来的是越来越多的软件项目的失败,造成项目失败的原因很多,但主要集中在开发过程,所以软件工程应运而生,CMMI等流程标准也是一茬接着一茬的冒个不停。
在软件工程初具规模的时候,软件开发还是以数据结构+算法的形式存在,进入20世纪最后10年,随着面向对象技术、设计模式等在开发过程中的成功应用,软件架构也走进了大家的视野。
软件架构在定义上分为‘组成派’和‘决策派’两大阵营,分别描述如下:'组成派‘认为软件架构是将系统描述成计算组件及组件之间的交互。
它有两个非常明显的特点:关注架构实践的客体——软件,以软件本身作为描述对象。
分析了软件的组成,说明软件不是一个‘原子’意义上的整体,而是有不同的部分经过特定的接口进行连接组成的一个整体,这对软件开发来说很重要。
'决策派'认为软件架构包含了一系列的决策,主要包括:软件系统的组织选择组成系统的结构元素和它们之间的接口,以及当这些元素相互协作时所体现的行为用于指导这个系统组织的架构风格:这些元素以及它们的接口、协作和组合软件架构并不仅仅关注软件本身的结构和行为,还注重其他特性:使用、功能性、性能、弹性、重用、可理解、经济以及技术的限制和权衡等。
'决策派'有以下两个显著的特点:关注软件架构中的实体——人,以人的决策为描述对象。
归纳了软件架构决策的类型,指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策,还包括关于众多非功能性需求的决策。
按照‘组成派’的观点,软件架构关注的是软件整体的分割和交互,之所以分割,是因为不同的部分在逻辑或物理上相对独立,通过‘分而治之’的原则进行分割可以更好的理解整个系统,把握用户的需求,但是虽然整个软件可以分割成多个模块或子系统,但是模块和子系统之间的通信和交互也是很重要的,我想按照这种观点,架构师的主要任务是将软件分割成不同的模块,并定义模块之间的接口。
按照‘决策派’的观点,软件是一个在很多限制下产生的产品,这些限制包括用户和技术两方面,用户方面包括功能需求、性能需求、硬件需求等,技术方面包括技术选择、可扩展性、可重用性、可维护性等。
我想按照这中观点,架构师的主要任务就是作出上述个各种限制作出选择或决策。
《软件架构设计》 温昱
什么是软件系统架构设计
展开全部 “架构”一词最早来自建筑学,原意为建筑物设计和建造的艺术。
但是在软件工程领域,软件架构不是一个新名词,只是在早期的著作中人们将软件架构称为软件体系架构。
这就是架构的概念。
所谓架构,就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。
系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段,同时利用各种学科技术完成子系统的结构构建。
在系统架构中,由于对软件越来越深入的依赖,软件架构的任务也体现出重要的作用。
而且系统架构与软件架构是紧密联系和相互依赖的。
1997年,Eberhadrt Rechtin 与MarkW Maier 在其论著中,为计算机科学总结了系统架构方面的实践成果,从而奠定了系统科学和系统架构在计算机科学中的基石: 无论何种系统架构应用领域,目的都是一样的,即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。
...
【系统架构和软件架构】正交软件架构方法
果你想要制作易于设计、构建、测试及扩展的系统,正交性是一个十分关键的概念,但是,正交性的概念很少被直接讲授,而常常是你学习的各种其他方法和技术的隐含特性。
这是一个错误。
一旦你学会了直接应用正交性原则,你将发现,你制作的系统的质量立刻就得到了提高。
什么是正交性 文本框: “正交性”是从几何学中借来的术语。
如果两条直线相交成直角,它们就是正交的,比如图中的坐标轴。
用向量术语说,这两条直线互不依赖。
沿着某一条直线移动,你投影到另一条直线上的位置不变。
在计算技术中,该术语用于表示某种不相依赖性或是解耦性。
如果两个或更多事物中的一个发生变化,不会影响其他事物,这些事物就是正交的。
在设计良好的系统中,数据库代码与用户界面是正交的:你可以改动界面,而不影响数据库;更换数据库,而不用改动界面。
在我们考察正交系统的好处之前,让我们先看一看非正交系统。
非正交系统 你正乘坐直升机游览科罗拉多大峡谷,驾驶员——他显然犯了一个错误,在吃鱼,他的午餐——突然呻吟起来,晕了过去。
幸运的是,他把你留在了离地面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 你不会与特定的供应商、产品、或是平台紧绑在一起,因为与这些第三方组件的接口将被隔离在全部开发的较小部分中。
让我们看一看在工作中应用正交原则的几种方式。
项目团队 你是否注意到,有些项目团队很有效率,每个人都知道要做什么,并全力做出贡献,而另一些团队的成员却老是在争吵,而且好像无法避免互相妨碍? 这常常是一个正交性问题。
如果团队的组织有许多重叠,各个成员就会对责任感到困惑。
每一次改动都需要整个团队开一次会,因为他们中的任何一个人都可能受到影响。
怎样把团队划分为责任得到了良好定义的小组,并使重叠降至最低呢?没有简单的答案。
这部分地取决于项目本身,以及你对可能变动的区域的分析。
这还取决于你可以得到的人员。
我们的偏好是从使基础设施与应用分离开始。
每个主要的基础设施组件(数据库、通信接口、中间件层,等等)有自己的子团队。
如果应用功能的划分显而易见,那就照此划分。
然后我们考察我们现有的(或计划有的)人员,并对分组进行相应的调整。
你可以对项目团队的正交性进行非正式的衡量。
只要看一看,在讨论每个所需改动时需要涉及多少人。
人数越多,团队的正交性就越差。
显然,正交的团队效率也更高(尽管如此,我们也鼓励子团队不断地相互交流)。
希望能帮到你,麻烦点击 好评,...
什么是系统架构设计?
不同的架构方法论,会将架构分为不同视图,每个视图侧重某一个方面、领域的问题。
比如希赛推的ADMEMS架构体系,分为以下几种视图:1. 数据架构:描述数据的存储结构、格式等方面。
2. 物理架构:描述机器的物理部署、网络拓扑方面。
3. 运行架构:描述运行期线程、进程间的交互工作机制。
4. 逻辑架构:指如何将代码分成不同模块、组件,以及之间的职责分配、交互行为。
5. 开发架构:主要指开发工具的选择,程序单元的划分,开发管理规范流程等方面。
例如分为哪些工程、项目,源代码管理,自动化编译构建、测试、部署等。
目前国际上运用比较广泛的是TOGAF架构体系,他把架构分为业务架构、数据架构、应用架构、技术架构等几个方面。
想详细的了解这些架构视图,可以参考这些架构体系相关的书、资料。
另外有很多人无缘无故的抨击架构概念,不知道是出于调侃还是无知。
埃及的金字塔、神庙的建设,不是几个平常的泥瓦匠聚在一起就能够造出来的。
像SAP、Oracle ERP,国内的金蝶等大规模的系统,以及空间站、火箭的控制系统等,没有系统性的架构方法、规范、流程,结果只能是悲剧。
当规模、复杂度没有达到一定程度,比如在一些小的团队、产品中,架构过程可能融入到老板、经理、组长、资历较深的一些开发者中,融入在大家的日常工作中,以至于感觉不到架构的存在。
就算遇到一些问题,因规模不大、复杂度不高,也比较容易调整。
当这些前提条件发生变化时,架构的作用和必要性就逐步的体现出来。
总的来说,一说到架构,如果懂软件,那么会了解为一个软件系统,这个软件设计的组成结构,如哪些是基础支持组件,哪些是完成A业务,哪些完成B业务……但说道企业架构的时候,就会问,该企业架构的几个架构如业务架构、数据架构、业务架构、技术架构,以及如何链接在一起。
倒觉得,一个企业确实需要这样的架构,但不要神话它,最主要的是业务如何最终体现到软件中和流程中。
而采取分离式设计时,最容易的错误就是各自为政,集成困难。
那么以数据为中心的架构设计,会自然提供集成的基础。
提到过,企业最重要的资产是数据,甚至不是信息,是数据。
企业的业务流程会变,IT系统会变,所需要的信息与知识会变,唯有数据能够积淀下来。
这有点象自然演进,考古那种,啥都
软件构架,架构和框架的区别
结构:程序功能实现的逻辑框架是整个或部分系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法;另一方面也可以说框架是可被应用开发者定制的应用骨架。
框架亦可称为应用架构,在特定领域基于体系结构的可重用的设计。
也可以认为框架是体系结构在特定领域下的应用。
框架的例子如MVC。
设计模式 在一定的环境中解决某一问题的方案 构件通常是代码重用,而设计模式是设计重用,框架则介于两者之间,部分代码重用,部分设计重用,有时分析也可重用. 构架是architecture:它是对软件系统的系统组织,是对构成系统的构件的接口,行为模式,协作关系等体系问题的决策总和。
它不仅涉及到结构与行为,而且还涉及到系统的使用,功能,性能,适应性,重用性,可理解性设计模式比框架更为抽象设计模式在碰到具体问题后,才能产生代码;框架已经可以用代码表示设计模式是比框架更小的体系结构元素:框架中可以包括多个设计模式简单点说:结构 <; 设计模式 <; 架构 <;框架 结构+算法=程序(功能代码块) 程序与程序之间进行调整=设计模式 多个设计模式相组合(组件)=架构(系统)
软件体系结构与软件架构有哪些区别?
软件体系结构与软件架构的中文翻译都是英文Software Architecture。
两者都使用一样的定义,如IEEE的“一个系统的基础组织,包含各个构件、构件互相之间与环境的关系,还有指导其设计和演化的原则。
”[IEEE-2000]为了找到两者的区别,得先从应用的环境入手。
我们利用网站搜索引擎对这个领域的常用关键词进行了检索,搜索区域分为开发者网站、所有网站、学术网站,结果如下(检索日期2007-04-08): ① http://www-128.ibm.com/developerworks/cn ② http://www.miscrosoft.com/china ③ google.com 采用精确匹配。
“架构师”改为“软件架构师”,“架构设计师”改为“软件架构设计师”减少领域差异 ④ baidu.com 采用精确匹配。
“架构师”改为“软件架构师”,“架构设计师”改为“软件架构设计师”减少领域差异 ⑤ http://www.cnki.net/index.htm采用精确匹配。
中国期刊全文数据库(2000-2007) 结果表明,在软件开发者和软件应用者来说,倾向于使用“软件架构”,在一定程度上接受“软件体系结构”。
大家对软件架构的设计人员,“架构师”得到广泛的认同。
对于学术界,普遍使用“软件体系结构”,对架构师几乎没有关注。
Software Architecture是一个实践性非常强的领域,统计表明理论和实践的鸿沟还是存在的。
其次,我们从词源探讨“体系”“结构”“架构”的解释[字典-2001]。
体系:若干事物互相联系而构成的一个整体。
例思想~ | 工业~ 结构:①建筑物承受重量和外力的部分及其制造。
按材料分有钢结构、木结构、砖石结构、框架结构、砖混结构等。
按形式分有悬索结构、拱结构等。
②构成整体的各个部分及其结合方式。
例经济~│文章~。
③文艺作品的内部构造。
即作品的各部分(包括内容和形式)之间有机的组织联系。
架构:①建造;构筑。
②框架;支架。
③比喻事物的组织、结构、格局。
例市场~│故事~庞大 通过以上分析,我们不难看出学术界为什么用“软件体系结构”。
首先,体系结构的中文定义完全符合IEEE等的定义。
强调整体与部分,部分与部分的关系;研究系统构成的方法学;提倡多角度研究系统。
其次,从学科地位讲,作为一门独立软件子学科,和硬件学科(计算机组织与体系结构)直接对应。
从工程实践需要看,软件架构更能体现系统构成与相关技术。
RUP过程或软件生产线关注的软件架构并不注重原理及表示,而是由结构和技术相结合的形成框架。
软件架构在中文中很容易与软件框架(Software Framework)混淆,对于一个应用的软件框架通常称为应用程序框架(Application Framework)。
框架是为了构建完整的应用而必须详细阐述的一种程序结构[Johnson-88]。
框架在RUP和软件产品线开发过程中是一个非常重要的过程。
RUP中框架是细化阶段的一个制品,软件产品生产线中是一组应用共享的程序框架。
目前,没有文献表明软件体系结构与软件架构的差别。
如果你强调方法论,应使用软件体系结构。
强调软件开发实践,应使用软件架构。
什么是分布式系统架构
分布式应用程序就是指应用程序分布在不同计算机上,通过网络来共同完成一项任务,通常为服务器/客户端模式。
更广义上理解“分布”,不只是应用程序,还包括数据库等,分布在不同计算机,完成同一个任务。
之所以要把一个应用程序分布在不同的计算机上,主要有两个目的:1) 分散服务器的压力大型系统中,模块众多,并发量大,仅用一个服务器承载往往会发生压力过大而导致系统瘫痪的情况。
可以在横向和纵向两方面来进行拆分,把这些模块部署到不同的服务器上。
这样整个系统的压力就分布到了不同的服务器上。
l 横向:按功能划分。
l 纵向:N层架构,其中的一些层分布到不同的服务器上(分层的概念会在后文进行介绍)。
2) 提供服务,功能重用使用服务进行功能重用比使用组件进行代码重用更进一层。
举例来说,如果在一个系统中的三个模块都需要用到报表功能,一种方法是把报表功能做成一个单独的组件,然后让三个模块都引用这个组件,计算操作由三个模块各自进行;另一种方法是把报表功能做成单独的服务,让这三个模块直接使用这个服务来获取数据,所有的计算操作都在一处进行,很明显后者的方案会比前者好得多。
服务不仅能对内提供还能对外提供,如果其他合作伙伴需要使用我们的报表服务,我们又不想直接把所有的信息都公开给它们。
在这种情况下组件方式就不是很合理了,通过公开服务并对服务的使用方做授权和验证,那么我们既能保证合作伙伴能得到他们需要的数据,又能保证核心的数据不公开。
编写软件架构文档说明,第 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 参与者传达有关该不断发展的系统的信息。
软件架构具有一组其预期要满足的业务和工程目标。
体系结构的文档说明可以向参与者传达这些目标将如何实现。
为体系结构的各个方面编写文档说明,有助于架构师弥补用白板描述解决方案(使用框线图方法)与以对下游设计和实现团队有意义的方式表示解决方案之间众所周知的差距。
体系结构的框线图留下了大量有待解释的空间。
需要揭示的细节通常隐藏并令人混淆地固守在那些框线背后。
文档说明还可以促进创建切合实际并且可以系统开发(例如遵循标准模板)的体系结构构件。
作为一门学科,软件架构是非常成熟的。
您可以利用最佳实践和指导...