软件开发常用的框架有哪些
展开全部 “架构”一词最早来自建筑学,原意为建筑物设计和建造的艺术。
但是在软件工程领域,软件架构不是一个新名词,只是在早期的著作中人们将软件架构称为软件体系架构。
这就是架构的概念。
所谓架构,就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。
系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段,同时利用各种学科技术完成子系统的结构构建。
在系统架构中,由于对软件越来越深入的依赖,软件架构的任务也体现出重要的作用。
而且系统架构与软件架构是紧密联系和相互依赖的。
1997年,Eberhadrt Rechtin 与MarkW Maier 在其论著中,为计算机科学总结了系统架构方面的实践成果,从而奠定了系统科学和系统架构在计算机科学中的基石: 无论何种系统架构应用领域,目的都是一样的,即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。
...
什么是系统架构设计?
不同的架构方法论,会将架构分为不同视图,每个视图侧重某一个方面、领域的问题。
比如希赛推的ADMEMS架构体系,分为以下几种视图:1. 数据架构:描述数据的存储结构、格式等方面。
2. 物理架构:描述机器的物理部署、网络拓扑方面。
3. 运行架构:描述运行期线程、进程间的交互工作机制。
4. 逻辑架构:指如何将代码分成不同模块、组件,以及之间的职责分配、交互行为。
5. 开发架构:主要指开发工具的选择,程序单元的划分,开发管理规范流程等方面。
例如分为哪些工程、项目,源代码管理,自动化编译构建、测试、部署等。
目前国际上运用比较广泛的是TOGAF架构体系,他把架构分为业务架构、数据架构、应用架构、技术架构等几个方面。
想详细的了解这些架构视图,可以参考这些架构体系相关的书、资料。
另外有很多人无缘无故的抨击架构概念,不知道是出于调侃还是无知。
埃及的金字塔、神庙的建设,不是几个平常的泥瓦匠聚在一起就能够造出来的。
像SAP、Oracle ERP,国内的金蝶等大规模的系统,以及空间站、火箭的控制系统等,没有系统性的架构方法、规范、流程,结果只能是悲剧。
当规模、复杂度没有达到一定程度,比如在一些小的团队、产品中,架构过程可能融入到老板、经理、组长、资历较深的一些开发者中,融入在大家的日常工作中,以至于感觉不到架构的存在。
就算遇到一些问题,因规模不大、复杂度不高,也比较容易调整。
当这些前提条件发生变化时,架构的作用和必要性就逐步的体现出来。
总的来说,一说到架构,如果懂软件,那么会了解为一个软件系统,这个软件设计的组成结构,如哪些是基础支持组件,哪些是完成A业务,哪些完成B业务……但说道企业架构的时候,就会问,该企业架构的几个架构如业务架构、数据架构、业务架构、技术架构,以及如何链接在一起。
倒觉得,一个企业确实需要这样的架构,但不要神话它,最主要的是业务如何最终体现到软件中和流程中。
而采取分离式设计时,最容易的错误就是各自为政,集成困难。
那么以数据为中心的架构设计,会自然提供集成的基础。
提到过,企业最重要的资产是数据,甚至不是信息,是数据。
企业的业务流程会变,IT系统会变,所需要的信息与知识会变,唯有数据能够积淀下来。
这有点象自然演进,考古那种,啥都
软件开发过程一般有几个阶段
软件开发一般分为五个阶段:1.问题的定义及规划此阶段是软件开发与需求放共同讨论,主要确定软件的开发目标及其可行性。
2.需求分析在确定软件开发可行性的情况下,对软件需要实现的各个功能进行详细需求分析。
需求分析阶段是一个很重要的阶段,这一阶段做的好,将为整个软件项目的开发打下良好的基础。
“唯一不变的是变化本身”,同样软件需求也是在软件爱你开发过程中不断变化和深入的,因此,我们必须定制需求变更计划来应付这种变化,以保护整个项目的正常进行。
3.软件设计此阶段中偶要根据需求分析的结果,对整个软件系统进行设计,如系统框架设计、数据库设计等。
软件设计一般分为总体设计和详细设计。
还的软件设计将为软件程序编写打下良好的基础。
4.程序编码此阶段是将软件设计的结果转化为计算机可运行的程序代码。
在程序编码中必定要制定统一、符合标准的编写规范。
以保证程序的可读性、易维护性。
提高程序的运行效率。
5.软件测试在软件设计完成之后要进行严密的测试,一发现软件在整个软件设计过程中存在的问题并加以纠正。
整个测试阶段分为单元测试、组装测试、系统测试三个阶段进行。
测试方法主要有白盒测试和黑盒测试。
以上就是软件开发过程的五个阶段,但是有的时候在软件爱你开发过程中并不是必须按照这个过程进行的。
数据流图,程序结构图和系统结构图的区别和联系
展开全部 1.数据流图(Data Flow Diagram),简称DFD,它从数据传递和加工角度,以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程,是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
它是描绘信息流和数据从输入移动到输出的过程中所经受的变换。
其主要元素有:→:数据流 □:数据源(终点) ○:对数据的加工(处理) 〓:数据存储2.系统流程图(System Flowchart)是描绘系统物理模型的传统工具。
它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个部件(程序、文件、数据库、表格、人工过程等),表达信息在各个部件之间流动的情况,而不是表示对信息进行加工处理的控制过程。
系统流程图:反应主体框架 数据流程图:反应数据走向 它不考虑时序关系,是业务分析用的,用作详细设计。
图中的有向线段表示了数据流程序流程图:程序逻辑 描述程序中控制流的情况,即程序中处理的执行顺序和执行序列所依赖的条件,图中的有向线段表示的是控制流,从一个处理走到下一个处理系统结构图:反映的是系统中模块的调用关系和层次关系,谁调用谁,有一个先后次序(时序)关系。
图中的有向线段表示调用时程序的控制从调用模块移到被调用模块,并隐含了当调用结束时控制将交回给调用模块.
软件体系结构的应用现状
形成研究热点,仍处于非形式化水平自20世纪90年代后期以来,软件体系结构的研究成为一个热点。
广大软件工作者已经认识到软件体系结构研究的重大意义和它对软件系统设计开发的重要性,开展了很多研究和实践工作。
从软件体系结构研究的现状来看,当前的研究和对软件体系结构的描述,在很大程度上来说还停留在非形式化的基础上。
软件构架师仍然缺乏必要的工具,这种工具应该是显式描述的、有独立性的形式化工具。
在目前通用的软件开发方法中,其描述通常是用非形式化的图和文本,不能描述系统期望的存在于构件之间的接口,不能描述不同的组成系统的组合关系的意义。
难以被开发人员理解,更不能用来分析其一致性和完整性等特性。
当一个软件系统中的构件之间几乎以一种非形式化的方法描述时,系统的重用性也会受到影响,在设计一个系统结构过程中的努力很难移植到另一个系统中去。
对系统构件和连接关系的结构化假设没有得到显式的、形式化的描述时,把这样的系统构件移植到另一个系统中去将是有风险的,甚至是不可能的。
软件体系结构的形式化方法研究软件体系结构研究如果仅仅停留在非形式化的框图阶段,已经难以适应进一步发展的需要。
为支持基于体系结构的开发,需要有形式化建模符号、体系结构说明的分析与开发工具。
从软件体系结构研究的现状来看,在这一领域近来已经有不少进展,其中比较有代表性的是美国卡耐基梅隆大学(Carnegie Mellon University)的Robert J.A11en于l997年提出的Wright系统。
Wright是-种结构描述语言,该语言基于一种形式化的、抽象的系统模型,为描述和分析软件体系结构和结构化方法提供了一种实用的工具。
Wright主要侧重于描述系统的软件构件和连接的结构、配置和方法。
它使用显式的、独立的连接模型来作为交互的方式,这使得该系统可以用逻辑谓词符号系统,而不依赖特定的系统实例来描述系统的抽象行为。
该系统还可以通过一组静态检查来判断系统结构规格说明的一致性和完整性。
从这些特性的分析来说,Wright系统的确适用于对大型系统的描述和分析。
软件体系结构的建模研究研究软件体系结构的首要问题是如何表示软件体系结构,即如何对软件体系结构建模。
根据建模的侧重点的不同,可以将软件体系结构的模型分为5种:结构模型、框架模型、动态模型、过程模型和功能模型。
在这5个模型中,最常用的是结构模型和动态模型。
(1)结构模型这是一个最直观、最普遍的建模方法。
这种方法以体系结构的构件、连接件和其他概念来刻画结构,并力图通过结构来反映系统的重要语义内容,包括系统的配置、约束、隐含的假设条件、风格、性质。
研究结构模型的核心是体系结构描述语言。
(2)框架模型框架模型与结构模型类似,但它不太侧重描述结构的细节而更侧重于整体的结构。
框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
(3)动态模型动态模型是对结构或框架模型的补充,研究系统的大颗粒的行为性质。
例如,描述系统的重新配置或演化。
动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。
这类系统常是激励型的。
(4)过程模型过程模型研究构造系统的步骤和过程。
因而结构是遵循某些过程脚本的结果。
(5)功能模型该模型认为体系结构是由一组功能构件按层次组成,下层向上层提供服务。
它可以看作是一种特殊的框架模型。
这5种模型各有所长,也许将5种模型有机地统一在一起,形成一个完整的模型来刻画软件体系结构更合适。
例如,Kruchten在1995年提出了一个4+1的视角模型。
4+1模型从5个不同的视角包括逻辑视角、过程视角、物理视角、开发视角和场景视角来描述软件体系结构。
每一个视角只关心系统的一个侧面,5个视角结合在一起才能够反映系统的软件体系结构的全部内容。
4+1模型如图1所示。
图1 4+1模型发展基于体系结构的软件开发模型软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的全部工作和任务的结构框架,给出了软件开发活动各阶段之间的关系。
目前,常见的软件开发模型大致可分为三种类型:(1)以软件需求完全确定为前提的瀑布模型。
(2)在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型,如螺旋模型等。
(3)以形式化开发方法为基础的变换模型。
所有开发方法都是要解决需求与实现之间的差距。
但是,这三种类型的软件开发模型都存在这样或那样的缺陷,不能很好地支持基于软件体系结构的开发过程。
因此,研究人员在发展基于体系结构的软件开发模型方面做了一定的工作。
例如,为了形象地表示体系结构的生命周期,北京邮电大学的周莹新博士建立了一个软件体系结构的生命周期模型,该模型如图2所示。
图2 软件体系结构的生命周期模型软件产品线体系结构的研究软件体系结构的开发是大型软件系统开发的关键环节。
体系结构在软件生产线的开发中具有至关重要的作用,在这种开发生产中,基于同一个软件体系结构,可以创建具有不同功能的多个系统。
在软件产品族之间共享体系结构和一组可重用的构件,可以增加软件工程和降低开发和维护成本。
一个产品线代表...
系统架构图的类别
逻辑架构图、部署架构图、运行架构图、网络架构图,再加上一个数据架构图,称为架构5视图或4+1视图,为什么有那么多视图呢,是因为架构不是那么简单那么容易理解的,不同人不同角度会有不同的看法,5个视图差不多就是同一个事物的5种看法吧。
至于架构的意思、区别,我就不打字了,从其它地方弄了一个过来,供参考:5视图法可以帮助软件架构师以不同的视角对软件的各个方面的属性:功能需求,约束,运行期质量属性,开发期质量属性。
1、 逻辑架构:逻辑架构关注功能,不仅包括用户可见的功能,还包括为实现用户功能而必须提供的“辅助功能模块”——。
2、 开发架构:开发架构关注程序包,不仅包括要编写的源程序,还包括可以直接使用的第三方SDK和现场框架、类库,以及开发的系统将运行于其上的系统软件或中间件。
关注编译时刻的静态依赖关系。
3、 运行架构:运行架构关注进程、线程、对象等运行时概念,以及相关的并发,同步,通信等问题。
运行架构关注运行期间各个单元的交互。
4、 物理架构:物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器,以及如何部署机器和网络来配合软件系统的可靠性,可伸缩性等要求。
5、 数据架构:数据架构关注持久化数据的存储方案,不仅包括实体及实体关系的存储格式、还包括数据传递,数据复制,数据同步等策略。