如何对软件架构建模

# 如何对软件架构建模
根据侧重点不同可分为5种模型

结构模型
--
以架构的构件、连接件和其他概念来刻画结构,并力图通过结构来反映系统的重要语义内容,包括系统的配置、约束、隐含的假设条件、风格、性质等。

框架模型
--
不太侧重描述结构的细节而更侧重于整体的结构。主要以一些特殊的问题为目标建立只针对和适应该问题的结构。

动态模型
--
对结构或框架模型的补充,研究系统的“大颗粒”的行为性质。例如描述系统的重新配置或演化。系统总体结构的配置、建立或拆除通信通道或计算的过程。

过程模型
--
研究构造系统的步骤和过程。

功能模型
--
认为架构是由一组功能构件按层次组成,下层向上层提供服务。可看作一种特殊的框架模型。

最常用的是结构模型和动态模型。将5种有机地结合形成一个完整的模型来刻画软件架构更合适。

## 4+1视图模型

从5个不同的视角来描述软件架构。

逻辑视图
--
最终用户:功能需求

可以用对象模型来代表逻辑视图,用类图来描述逻辑视图。设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。

进程视图
--
系统集成人员:性能、可扩充性、吞吐量等

侧重于系统的运行特性,主要关注一些非功能性的需求,例如系统的性能和可用性。强调并发性、分布性、系统集成性和容错能力,以及逻辑视图中的主要抽象如何适合进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。可以描述成多层抽象,每个级别分别关注不同的方面。

物理视图
--
系统工程人员:系统拓扑、安装、通信等。

主要考虑如何把软件映射到硬件上,它通常要考虑解决系统拓扑结构、系统安装、通信等问题。当然间运行于不同的结点上时,各视图中的构件都直接或间接地对应于系统的不同结点上。因此,从软件到结点的映射要有较高的灵活性,当环境改变时,对系统其他视图的影响最小。

开发视图
--
编程人员:软件管理

也称模块视图。主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织,这样对于一个软件系统就可以由不同的人进行开发。开发视图要考虑软件的内部需求,如软件开发的容易性、软件的重用和软件的通用性。要具体考虑开发工具的不同而带来的局限性。开发视图通过系统输入输出关系的模型图和子系统图来描述。

场景视图
--
可以看作是那些重要系统活动的抽象,它使四个视图有机联系起来,从某种意义上说场景是最重要的需求抽象。在开发架构时,它可以帮助设计者找到架构的构件和它们之间的作用关系。同时,也可以用场景来分析一个特定的视图,或描述不同视图构件间时如何互相作用的。场景可以用文本表示,也可以用图形表示。

逻辑视图和开发视图描述系统的静态结构,
而进程视图和物理视图描述系统的动态结构。
对于不同的软件系统来说,
侧重点也有锁不同。
例如,对于管理信息系统来说,比较侧重从逻辑视图和开发视图来描述系统。
而对于实时控制系统来说,则比较注重于从进程视图和物理视图来描述系统。

原文地址:https://www.cnblogs.com/13yan/p/9942115.html

时间: 2024-11-02 20:34:01

如何对软件架构建模的相关文章

论软件架构建模技术与应用

摘要:2010年,我参加了湖南某矿业的污水监控平台的开发,在这个项目中,我担任系统设计和开发的工作.这个系统主要是对辰州矿业的排污进行数据采集,实时监控,超标报警,数据统计和管理.本文结合作者的实践,以辰州矿业监控平台弟弟系统架构建模为例,论述了4+1视图模型在工作中的运用.本论文先介绍4+1模型,然后结合我参与项目的实际情况,详细说明在这次项目中所涉及的软件架构,最后是分析该项目取得实践效果. 正文 软件架构用来处理软件高层次结构的设计与实施,它以精心选择的形式将若干结构元素进行装配,从而满足

软件架构设计

软件架构概述 软件架构是具有一定形式的结构化元素,即构件的集合,包括处理构件.数据构件和连接构件.处理构件负责对数据进行加工,数据构件是被加工的信息,连接构件把架构的不同部分连接起来.软件架构是软件设计过程的一个层次,这一层次超越计算过程中的算法设计和数据库设计.架构问题包括总体组织和全局控制.通信协议.同步.数据存取,给设计元素分配特定功能,设计元素的组织,规模和性能,在各设计方案间进行选择等.软件架构处理算法与数据结构之上关于整个系统结构设计和描述方面的一些问题,如全局组织和全局控制结构.关

系统分析师教程——目录

第1章 绪论 1.1信息与信息系统 1.2系统分析师 第2章 经济管理与应用数学 2.1会计常识 2.2会计报表 2.3现代企业组织结构 2.4业绩评价 2.5企业文化管理 2.6IT审计相关常识 2.7概率统计应用 2.8图论应用 2.9组合分析 2.10算法的选择与应用 2.11运筹方法 2.12数学建模 第3章 操作系统基本原理 3.1操作系统概述 3.2进程管理 3.3内存管理 3.4文件系统 第4章 数据通信与计算机网络 4.1数据通信基础知识 4.2网络体系结构与协议 4.3局域网与

系统架构师设计师考试范围

工作好多年了,在硬件,软件,通信等方面都有好几年历练了,近来准备考系统架构师了,一:有工作经验考这个更合适些,二:可以丰富下自己的理论知识.三:可以发现弥补自身存在的不足,没什么坏处.最近买了一本<系统架构师设计师教程>,发现要考的东西还是很多的,要学习的东西还是挺多的,有操作系统的,数据库,测试方面的,数据通信,开发,虚拟化方面的,下面拿其大致罗列下,准备朝这方面努力. =============================================================

我的路子 - 发现游戏为模型的软件架构方式

总觉得如果一个内容被深刻地理解了,那么当在他口中说出来的时候,应该是很简单才对. 所以一直觉得,编程里那些不容易理解的,需要记住很多内容的东西都是有缺陷的.自己又比较自我认可强,看不到别人的角度,表现上有些自我.自己想的只是,事情还有很多解决方法,为什么要被那一种很难学的方式占了路子,而且找不到理解透彻的,有点为这种状况气愤,觉得肯定是没有好好做的原因,或者是一些人太安于现状的原因,或者是一些找不到出路就说没出路的人,自己没吃透却站在高处误导别人,阻碍大部分人的进一步思考. 即使这样,自己该做的

从零开始编写自己的C#框架(28)——建模、架构与框架

文章写到这里,我一直在犹豫是继续写针对中小型框架的设计还是写些框架设计上的进阶方面的内容?对于中小型系统来说,只要将前面的内容进行一下细化,写上二三十章具体开发上的细节,来说明这个通用框架怎么开发的就已完全足够了,因为对于中小型系统来说,并不是很复杂,简单的了解三层架构就已经够用了,而使用太多的设计反而有点罗嗦,因为基本上没有什么人会为中小型系统花费太多的设计工作.而对于设计大型平台的框架设计,又深深感到自己的积累还远远不够,写出来怕会误导大家.但不换个思维来讲述也很难说清框架的设计思想,别人拿

软件架构模式—分层模式

架构模式是什么 软件架构模式,诞生于软件开发的最大难题--需求变更.由于需求变更,导致了大量项目因为超出预算的人力.时间而归于失败.软件开发成本有限的,但需求变更似乎是无限的,这成为了一个非常难解决的问题. 软件需求变更的结果,基本上就是对于软件代码的修改.而软件代码的修改却是程序员们最头疼的事情.因为一些大型系统,其代码根本就无法完全看懂,即便能了解部分细节,在着手修改的时候,也会碰到"触一发而动全身"的问题:因为有些功能的修改,需要修改整个系统的很多部分,导致了无穷的BUG.另外一

软件架构漫谈--读感

在我看来,软件架构就是一个软件的骨架,然后用代码去填充皮肉.很明显我的认识相当肤浅,且停留在表面汉语理解意思.那么到底怎样去理解软件架构和使用软件架构? (1)架构是基于人的群居(以人为本)和一个为了提高生产力的目的(问题的本质)的一种分工处理和合并联系.我的理解是分工是模块,合并是组装,联系是组装方式. (2)要做好架构,首先要对概念有正确的认识.也就是透过现象看本质上所要解决的问题. (3)明白“是谁的问题,是什么问题”.首先是确定概念的主语,因为主语不同,理解不同,就像用户和技术员对待问题

嵌入式软件架构

嵌入式软件架构 软硬件模型 不管是通信互联系统,图形图像,音频视频,一个满足某种需求的业务应用,都常常需要协同使用硬件和软件来配合完成.硬件快,天然的具备处理数字的或模拟的信号的能力:软件灵活,可配置可定制可更新.那些固定的算法或已经成为业界标准的成熟规格,不像面向用户的使用场景一样会频繁修改,但对性能指标有高要求,比如MPEG编解码,颜色空间转换,还有那些离不开硬件实现的协议物理层(比如有对模拟信号的快速处理),你很难想象现在手机里是软件在做视频流解码,OPENGL渲染或者wifi的物理层信道