图说软件架构设计

什么是架构?

从前,有五个盲人,从来没有见过大象,不知道大象长的什么样,他们就决定去摸摸大象。第一个人摸到了鼻子,他说:“大象像一条弯弯的管子。”第二个人摸到了尾巴,他说:“大象像个细细的棍子。”第三个人摸到了身体,他说:“大象像一堵墙。”第四个人摸到了腿,他说:“大象像一根粗粗的柱子。”

盲人摸象的寓言含义: 看事情要全面,整体,不要分割开来。坚信自己的观点和坚持自己的观点很重要,学会听别人的观点,会把事情了解得更全面,更准确。

架构的原理

企业架构是一种对企业多角度的综合描述,它反映了企业的人、流程、技术的组织和安排。对于企业的不同参与者,企业架构提供了不同的视图,用他们容易理解的方式和语言反映企业的状态。

架构设计多视图方法示意

企业架构的多视角——Zachman框架

Zachman框架是一个6×6矩阵:纵向从规划者、所有者、设计者、承建者、分包者和最终用户六个视角来划分,建立目标/范围、业务模型、系统模型、技术模型、详细表达、运行功能等模型;横向从数据(What)、功能(How)、网络(Where)、人员(Who)、时间(When)、动机(Why)等6个方面的模型,并分别由实体-关系模型(Entity-Relationship)、流程-I/O模型(Input-Process-Output)、节点-链接模型(Node-Link)、人员-工作模型(People-Work)、时间-周期模型(Time-Cycle)、目标-手段模型(Ends-Means)来表达。

Zachman架构框架共分为5个层次,以5行来描述。每一行代表不同类型的项目涉众的看法和观点,它明确了企业架构工作的流程和流程承担者。

架构的三个层次

架构视角是从一个或多个角度对软件体系架构的各个方面进行关注,它反映了软件体系架构的一个或多个利益相关者的不同关注层面。

企业架构内容框架

架构设计成果——核心视图

时间: 2024-07-29 21:02:57

图说软件架构设计的相关文章

SoC嵌入式软件架构设计之四 :内存空间规划分配

本文继续阐述基于低端控制器CPU的SoC固件架构设计.第一节 SoC嵌入式软件架构设计之一:系统内存需求评估 讲述了系统内存需求的评估.这一节讲述内存空间的具体规划分配.CPU有两种体系结构:哈佛结构和冯诺依曼结构.哈佛结构是一种将程序指令存储和数据存储分开的存储器结构,如80251,代码空间与数据空间完全分开,独立编址:冯诺依曼结构是一种将程序指令存储器和数据存储器合并在一起的存储器结构,如MIPS,ARM等,其代码和数据空间是统一编址.这里就以冯诺依曼体系结构为例. 一.嵌入式系统软件分层

软件架构设计的目的

软件架构设计的目的简单说就是在保持软件内在联系的前提下,分解软件系统,降低软件系统开发的复杂性,而分解软件系统的基本方法无外乎分层和分割.但是在保持软件内在联系的前提下,如何分层分割系统,分层分割到什么样的粒度,并不是一件容易的事,这方面有各种各样的分解方法,比如:关注点分离,面向方面,面向对象,面向接口,面向服务,依赖注入,以及各种各样的设计原则等, 耦合可以分为以下几种,它们之间的耦合度由高到低排列如下: (1) 内容耦合:一个模块直接访问另一模块的内容,则称这两个模块为内容耦合. 若在程序

软件架构设计系列总结

架构引用维基百科:软件体系结构是构建计算机软件实践的基础.与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础.从和目的.主题.材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟.一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计.软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作.逻辑和流程.软件

SoC嵌入式软件架构设计之三:代码分块(Bank)设计原则

上一节讲述了在没有MMU的CPU(如80251.MIPS M控制器系列.ARM cortex m系列)上实现虚拟内存管理的集成硬件设计方法,新设计的内存管理管理单元要实现虚拟内存管理还需要操作系统.代码分块(Bank)的支持,详见SoC嵌入式软件架构设计之二:没有MMU的CPU实现虚拟内存管理的设计方法.这里要阐述Bank设计的一些原则. Bank设计是为了实现不同时刻运行的Bank(代码块)运行在同一块内存上,所以在运行之前操作系统需要将已存在内存的代码/数据进行缓存处理,并加载将要运行的Ba

软件架构设计箴言理解

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 今天和师弟聊天聊到他们项目开发,有些同事总是提前考虑性能优化,需求变更又是一大堆的重写,让我想起了Donald Knuth 提到的:对软件的过早地优化是万恶的根源.这里就简单的说几条重要的软件名人哲学. 1:软件中唯一不变的就是变化. 在软件开发过程中需求是不停的变化,随着客户对系统的认识,和现有开发功能和软件的认识,也许以开始他提出的需求就是背离的.记得网上有一句笑话,师说需求变化的: 程

软件架构设计学习总结

软件架构设计就是软件系统的'布局谋篇',是软件抽象发展到一定阶段的产物.软件设计人员学习软件架构知识,旨在站在较高的层面上,整体的解决好软件的设计,复用,质量和维护等方面的实际问题.本文以图形的方式进行总结归纳,从软件架构的描述,设计,风格,评价,形成方法进行阐述. 软件架构设计总述: 软件架构的概念 软件架构的意义 软件架构的风格 分层架构 面向服务的架构(SOA) 特定领域的架构(DSSA) 软件产品线 基于架构的软件开发(ABSD) 软件架构与质量属性 软件架构评估 -----------

敏捷开发下的软件架构设计与持续优化

过往的软件开发, 往往都是由架构师将他对产品的理解,利用 UML 来体现软件的架构设计. 这种方式的问题是:因缺乏使用者与团队成员间的互动参与,使得对外并未能完整的将使用者需求,映射到软件架构中; 而对内所提供的软件架构设计文档, 对实际开发的工作, 指导意义并不大(因为,厚重的架构设计文档,便如老太婆的裹脚布般:又臭又长).更严重的问题是,由于架构设计耗费太长的时间,如此再加上开发.测试的时间,团队往往会太晚才会发现软件架构上的重大缺陷.而由于太晚才发现软件架构上的缺陷,所以,软件架构上若需做

(转)软件架构设计

[一]-软件架构设计过程 软件架构设计尚没有万灵的方法论支持,还是个非常新兴的行业,给出个人理解的行业软件架构设计过程,受个人水平有限,仅供参考: 1.业务分析:针对目标行业的业务战略.蓝图.业务功能及流程进行分析,提出其中部分功能可以使用信息化进行处理,通过分析可以得出信息化要解决的问题. 2.解决方案设计:根据业务战略,形成行业信息化解决方案.他是一个系统组,同时明确各系统间的支撑关系. 3.系统功能设计:明确信息化系统功能列表及功能层次(层次,例如经验决策层工,管理层功能,业务操作功能等)

详细介绍软件架构设计的三个维度

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 架构设计是一个非常大的话题,不管写几篇文章,接触到的始终只是冰山一角,更多的是实践中去体会.这篇文章主要介绍面向对象OO.面向方面AOP和面向服务SOA这三个要素在架构设计中的位置与作用. 架构设计有三个维度,或者说是我们在考虑架构时需要思考三个方向. 这三个维度分别为面向对象.面向方面.面向服务. 这三个维度可以看作是正交的,但不同维度会互相印证,互相支撑,整个架构的示意图如图所示. 面向