如何做好架构设计与写好架构设计的文档?
2 一下是我的写文档的一些心得:现代架构设计文档的编写4+1 视图与 UML 软件架构设计已经逐渐成为现代软件开发过程的核心,然而能够清晰表明架构设计并不是一件容易的事,就面向对象开发而言, RUP 的 4+1 视图已在架构设计的撰写中得到了广泛的应用和认可。
对于 4+1 view 的描述有几个不同版本(或包含的视图不同,或视图的名称不同),文中以 Philippe Kruchten, November 1995 提出的 4+1 视图为准。
4+1 视图包括:逻辑视图( Logic View ),开发视图( Develop View ),进程视图( Process View ),物理视图( Physical View )和场景视图( Scenarios )。
视图间的关系4+1 视图不仅便于我们记录架构设计,实际上它也指导了我们进行架构设计活动的部分过程。
通常我们选择 UML 来表现各种视图,以下列出了 UML 和各视图的对应关系4+1 视图 UML场景视图 use case逻辑视图 类图开发视图 类图,组件图进程视图 无完全对应部署视图 部署图在架构设计稳定中通常不会给出较多的用例描述,这些是在需求稳定中定义。
但是往往架构文档会选择一些用例,列入文档中,这些用例和一些非功能性需求一起用以证明架构的有效和正确性。
在逻辑视图中用例的实现是必不可少的一节,尽管架构设计更关注非功能性需求。
融入 MDA 的思想 对于逻辑视图和开发视图所应包含的内容常常会觉得很难区分两者间的明显界限。
逻辑视图包含更多的分析模型与实现技术本身相关性应该较少,如业务对象模型及其扩展。
而开发视图则会与实现技术紧密相关。
随着 MDA 思想的推广,在架构设计文档的撰写方面也产生了影响,我们不难把 MDA 的 PIM 和逻辑视图联系起来,而把 MDA 中的 PSM 和开发视图联系起来。
在编写逻辑视图是我们应该描述与技术平台无关的模型,而开发视图则描述与实现技术平台相关的模型。
如在逻辑视图中表现的某些实体类,我们会在开发视图中转换为 EJB 组件(实体 Bean )。
这种做法不仅有利于我们编写架构设计文档,同时更是一种好的架构设计思考流程。
什么是软件系统架构设计
展开全部 软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。
软件架构描述的对象是直接构成系 统的抽象组件。
各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。
在面向 对象领域中,组件之间的连接通常用接口_(计算机科学)来实现。
软件体系结构是构建计算机软件实践的基础。
与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念,多数工程师(尤其是经验不多的工程师)会从直觉上来认识它,但要给出精确的定义很困难。
特别是,很难明确地区分设计和构架:构架属于设计的一方面,它集中于某些具体的特征。
在“软件构架简介”中,David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。
结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。
但构架不仅是结构;IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。
构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。
它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。
在Rational Unified Process 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。
一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管 理软件产品的高级设计。
软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作、逻辑和流程。
一般而言,软件系统的架构(Architecture)有两个要素: 它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的,而这些元件如何形成、相互之间如何发生作用,则是关于这个系统本身结构的重要信息。
详细地说,就是要包括架构元件(Architecture Component)、联结器(Connector)、任务流(Task-flow)。
所谓架构元素,也就是组成系统的核心"砖瓦",而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果,任务流则描述系统如何使用这些元件和联结器完成某一项需求。
建造一个系统所作出的最高层次的、以后难以更改的,商业的和技术的决定。
建造一个系统之前会有很多的重要决定需要事先作出,而一旦系统开始进行详细设计甚至建造,这些决定就很难更改甚至无法更改。
显然,这样的决定必定是有关系统设计成败的最重要决定,必须经过非常慎重的研究和考察。
想学软件架构设计,有什么好书推荐吗
展开全部 此文转载至:帐前卒1 前言软件架构设计是软件设计的一部分,相当于总体设计,是软件设计过程中一个决定性的环节,架构确定了,软件基本也就定型了。
而软件架构师则是软件项目的领军人物,是软件设计过程中最具挑战性的角色,从技术角度来讲,他承担了项目的成败责任。
EEEC给“架构师”的定义为“软件架构师是技术主管”,这就意味着他不仅要有高超的技术才能,还要有很好的领导才能,他的领导能力在团队中和软件质量控制中起着十分重要的作用。
作为一个架构师,他要掌握整个软件项目的前景,调节各小组间关系,要让所有的项目组成成员了解大家共同的目的和目标,并发布标准和章程;要能正确理解软件过程,要在宏观上拥有专业知识,应该拥有很好的设计技巧;要是一个很好的沟通员和谈判代表,要能做出正确的决策等,除此,还有许多他要具备的其它素质。
2. 做好需求调研和分析为保证软件的可用性,要从需求出发设计架构,即:做软件先做需求,这是软件业内人士的共识,但这项工作做得好的却很少。
根据调查,属于需求分析和软件设计错误与缺陷的约占软件错误与缺陷的64%;而属于程序代码错误的仅占36%;而因软件错误积累与放大效应,造成整个软件项目拖延或失败情况的高达20%~60%。
这些数据表明,搞好需求调研和分析是软件设计和开发的第一步。
架构师必须要在需求调研的初期就介入,以保证需求获取的及时、可靠、准确,并对下步工作起指导作用。
进行需求调研,不能就事论事,对用户的需求调研要全面、细致。
需求要进行全局性的分析,需要有全局的观点,而不是分散地、根据具体的应用开发而进行的调研,这样才能系统地、本质地、概括地把握软件的功能结构。
在调研过程中,自始至终都要有用户方的业务人员参加,尤其是强调高层管理人员的重视和亲自参与,架构师及其相应的工作小组要有足够的沟通和理解能力,要能使业务人员在需求调研阶段起主导作用,架构师仅起协助和引导作用,并提供需求调研的科学方法和过程。
2.1 熟悉建设单位,定义职能域在需求调研阶段,架构师首先要全面了解用户中所有人员的需求,首先要了解建设单位的组织机构、业务关系,并根据建设单位中的一些主要业务活动领域,研究定义职能域,这是第一重要任务。
职能域是用户功能规划的抽象,应符合建设单位内部各种业务的逻辑关系,而不是现行机构部门的翻版,一经识别,就要保持相对稳定。
研制职能域模型时,需要特别注意,要自顶向下规划,并把握好设计职能域的数目;注意用户需求的主次关系,按照重要性、优先级进行权衡取舍。
2.2 详细调研各项业务过程及其功能分解每个职能域都包括一定数目的业务过程,业务过程可以继续分解为业务活动(对应于未来的软件功能),每个功能再分解为更低层的功能,逐级向下分解,直到产生最基本的、不可再分的最小功能单元。
职能域和业务过程都要独立于当前的组织机构,因为组织机构可能变化,部门的分工也会变化,但整个单位的基本职能和业务相对稳定。
职能域或业务过程可能横跨两个或多个业务部门。
业务过程的确定可以对照组织机构中各部门负责人的职责来考虑,这样,也可能获得未来软件的操作权限、数据权限的分配和功能模块的划分,这些业务过程是一个单位运作的基本工作,不受报告层次和具体负责人变动的影响。
调研前,架构师要对调研的内容事先准备,针对不同管理层的用户询问不同的问题,列出问题清单,将操作层、管理层、决策层的需求既联系又区分开来,形成一个金字塔,使下层满足上层的需求。
调研时,要收集用户工作中涉及的所有内容,如各种单据、报表、处理规则,再将其串成流程图,以流程图为主线,同时把握以下方面: (1)该流程中是否存在不必要的环节; (2)流程是否可以简化,是否可以省略一些环节; (3)流程中的每个处理环节是否起到了增值提效的作用; (4)哪些流程可以并行处理。
2.3 在调研具体业务时工作小组要把握的重点(1)平均频度 业务发生的频繁程度称为频度,这个数字可以是一个平均值或统计值。
频度越高,数据量越大,对响应时间、易操作性等要求就越高。
在数据存储时,对大频度的业务或单据要进行充分的考虑。
(2)高峰期的频度 必须保证软件在高峰期的响应时间,对软件进行测试时,要模拟高峰期的业务频度。
(3)单据要求 单据上的内容也就是单据的属性,它是进行数据结构设计的最基本依据。
数据的精度是定义数据库中字段长度的依据;计算生成方法是设计算法的依据;取值范围与计算生成方法是数据完整性检测的依据。
(4)利于减轻工作量 减轻人员的工作量是采用新软件的一个目的,花费时间最多、处理方法最复杂的地方往往是软件最关键的地方,也是用户将来验收时最关心的地方。
实际上有很多报表由于工作量相当大,用户没有足够的人力与时间来进行处理,这时他便想到了计算机。
(5)单据报表流程 要了解单据或报表的来源、单据联数、每联用途、送交单位、送交时间,对来源与去向的追踪可以调查出各个业务、各个单据、各个报表及各个部门之间的联系。
(6...
用什么工具画 软件架构设计图
UIDesigner是腾讯用户研究与体验设计部(CDC)设计研发的一款设计类软件,打造一款可以让设计师统一平台和团队协作的平台型设计工具,经过1.0和2.0版本的经验沉淀,我们决定对3.0版本进行全新的架构设计。
开发一个软件系统,前期的架构设计承载着整个软件的设计思想和关键决策,可以说是重中之重。
根据软件架构设计思想,关注分割和交互,好的架构必须使每个关注点相互分离。
我们进行了最基本的需求分析,得出两个关注点:一是工具,二是设计绘图,关系如图1所示。
得到最基本的两个关注点后,接着将提取关键需求(包括:关键功能需求、关键质量需求和关键商业需求),根据两个关注点进行架构的细化设计。
一、关注点——工具这里我们结合UIDesigner的实际需求,提取出属于“工具”范畴的关键功能需求、关键质量需求和关键商业需求。
首先,“工具”的关键功能需求,必须包括:磁盘文件读写、异常捕捉、日志记录、安全性管理;非工具所必须,但是UIDesigner本身所要求的,包括:配置管理、缓存管理、线程服务、服务器和客户端通讯管理、国际化服务。
其次,“工具”的关键质量需求,质量需求包括开发期质量需求和运行期质量需求两部分,经过分析和权衡,UIDesigner的性能主要取决于设计绘图,而稳定性、可扩展性和可维护性才是决定“工具”本身发展的质量需求,因此,对“工具”的质量需求设计将以稳定性、可扩展性和可维护性为主。
最后,“工具”的关键商业需求,因为UIDesigner本身并没有很复杂的业务需求,因此关键商业需求是在设计流程的优化和规范上得到体现,这方面的设计已经属于高层模块和使用流程的设计,对架构的影响非常小,可以暂时性的忽略。
经过关键需求的提取,我们得到了“工具”的设计目标——可以提供通用功能(关键功能需求)的高稳定性、扩展性和维护性的客户端应用。
根据此目标,我们采取了DI(Dependency-Injection)和MVP(Model-View-Presenter)结合的架构,概念架构设计如图2所示。
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语义模型的标志性的语言,也很难想象能在当前业务架构发挥太大影响。
但如果真如它所声称那样,广泛地改变着信息的结构。
那么对软件架构也会有深远影响。
什么是软件系统架构设计
“架构”一词最早来自建筑学,原意为建筑物设计和建造的艺术。
但是在软件工程领域,软件架构不是一个新名词,只是在早期的著作中人们将软件架构称为软件体系架构。
这就是架构的概念。
所谓架构,就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。
系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段,同时利用各种学科技术完成子系统的结构构建。
在系统架构中,由于对软件越来越深入的依赖,软件架构的任务也体现出重要的作用。
而且系统架构与软件架构是紧密联系和相互依赖的。
1997年,Eberhadrt Rechtin 与MarkW Maier 在其论著中,为计算机科学总结了系统架构方面的实践成果,从而奠定了系统科学和系统架构在计算机科学中的基石:无论何种系统架构应用领域,目的都是一样的,即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。
cad建筑结构设计用什么软件较好?
展开全部 不同的架构方法论,会将架构分为不同视图,每个视图侧重某一个方面、领域的问题。
比如希赛推的ADMEMS架构体系,分为以下几种视图: 1. 数据架构:描述数据的存储结构、格式等方面。
2. 物理架构:描述机器的物理部署、网络拓扑方面。
3. 运行架构:描述运行期线程、进程间的交互工作机制。
4. 逻辑架构:指如何将代码分成不同模块、组件,以及之间的职责分配、交互行为。
5. 开发架构:主要指开发工具的选择,程序单元的划分,开发管理规范流程等方面。
例如分为哪些工程、项目,源代码管理,自动化编译构建、测试、部署等。
目前国际上运用比较广泛的是TOGAF架构体系,他把架构分为业务架构、数据架构、应用架构、技术架构等几个方面。
想详细的了解这些架构视图,可以参考这些架构体系相关的书、资料。
另外有很多人无缘无故的抨击架构概念,不知道是出于调侃还是无知。
埃及的金字塔、神庙的建设,不是几个平常的泥瓦匠聚在一起就能够造出来的。
像SAP、Oracle ERP,国内的金蝶等大规模的系统,以及空间站、火箭的控制系统等,没有系统性的架构方法、规范、流程,结果只能是悲剧。
当规模、复杂度没有达到一定程度,比如在一些小的团队、产品中,架构过程可能融入到老板、经理、组长、资历较深的一些开发者中,融入在大家的日常工作中,以至于感觉不到架构的存在。
就算遇到一些问题,因规模不大、复杂度不高,也比较容易调整。
当这些前提条件发生变化时,架构的作用和必要性就逐步的体现出来。
总的来说,一说到架构,如果懂软件,那么会了解为一个软件系统,这个软件设计的组成结构,如哪些是基础支持组件,哪些是完成A业务,哪些完成B业务……但说道企业架构的时候,就会问,该企业架构的几个架构如业务架构、数据架构、业务架构、技术架构,以及如何链接在一起。
倒觉得,一个企业确实需要这样的架构,但不要神话它,最主要的是业务如何最终体现到软件中和流程中。
而采取分离式设计时,最容易的错误就是各自为政,集成困难。
那么以数据为中心的架构设计,会自然提供集成的基础。
提到过,企业最重要的资产是数据,甚至不是信息,是数据。
企业的业务流程会变,IT系统会变,所需要的信息与知识会变,唯有数据能够积淀下来。
这有点象自然演进,考古那种,啥都...