精华内容
下载资源
问答
  • 软件架构设计

    2017-05-04 07:45:49
    1. 软件架构设计的What & Why ● 啥是软件架构(Software Architecture)? 软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统的各个...
    

    1. 软件架构设计的What & Why


    ● 啥是软件架构(Software Architecture)?

    软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统的各个组件,组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

    软件架构设计就是从宏观上说明一套软件系统的组成与特性。

    软件架构设计是一系列有层次的决策 ,比如:功能与展现的决策;技术架构的决策;自主研发还是合作;商业软件还是开源软件 。


    为啥要进行软件架构设计?

    业务需求层出不穷;软件系统越来越复杂;参与的人越来越多;共性和特殊性的问题越来越多;技术发展日异月新;……


    2. 软件架构师


    2.1. 软件架构师是干什么的

    介于需求与开发的中间人     良好的沟通能力
    能够统领全局的大牛 良好的大局观
    能够将需求转换为技术     洞悉前沿与市场嗅觉
    能够为软件研发提供指导     见多识广的大牛
    需要全面思考软件系统方方面面的问题     缜密地思考问题
    能够攻关和搞定重要技术难题     公司可信赖的支柱


    2.2. 架构师的素质

    全局思维  

    从业务、市场,到技术实现;

    从软件的过去、现在,到将来;

    从外部客户,到内部研发;

    从软件研发,到硬件部署;

    从功能实现,到运行效率  

    战略思维  

    在所在行业的发展战略;

    在业务领域的发展战略;

    在技术方向的发展战略;

    在潜在市场的发展战略。

    前瞻思维  

    市场趋势的发展动向;

    前沿技术的发展动向;

    竞争对手的发展动向;

    合作伙伴的发展动向。

    抽象思维  

    各项业务需求:抽象成功能模块;

    各项功能的实现:抽象成软件架构。 

    逆向思维

    假如不实现会怎样?

    假如没搞定会怎样?

    假如没有它会怎样?

    假如被延期会怎样?


    2.3.  架构师的分类

    随着行业和社会的发展,架构师的定义和分类越来越广泛和细分,广泛和细分其实并不矛盾,如果“广泛”是x轴,“细分”是y轴,则二维坐标系x和y轴中间的任一点就是一种架构师类别。但总体来说,或目前来说,集合业界的大致认知,总结如下:

    No. 分类 描述
    1 解决方案架构师 与客户探讨业务需求,将业务、市场,与技术、产品结合起来,为客户提供解决他们需求的方案。
    2 系统架构师 也称应用架构师。最终确认和评估系统需求,并将业务转换为技术,为研发人员制订核心框架与技术规范 为研发工作澄清技术细节并扫清技术障碍 。
    3 平台架构师 这里的平台其实包括两个平台,一个是系统平台,也就是负责搭建多个系统整合的系统应用平台;另外一个其实是基础平台,是专门负责搭建基础技术平台;两者其 实区别蛮大,也经常容易被从业人员混乱。举个简单例子,金蝶有平台架构师一职,但是金蝶BOSS应用和金蝶中间件两者招聘的对象和技术要求是截然不同的。
    4 业务架构师 业务架构其实已经开始脱离技术层面了,但是它要求架构师有跨越多系统的大局观,去整合和组织不同系统的技术平台与交互模式。其实这个职位的未来也就是CIO了。
    5 网络架构师 过去,我们可能听的最多的是网络工程师。不错,一个优秀的网络架构师必须有足够的网络技术基底,并且它的关注点也是系统的基础架构。比如说如果搭建并优化集群环境,如果构建基于云计算的系统应用与部署等等。它对于像淘宝、腾讯这样的互联网公司是极其重要的。
    6 移动架构师 移动互联网的迅猛发展横向和纵向都细分出了很多新的职责和岗位,移动架构师的职责和作用日益重要,既要整体和全局考虑整个前后端的软件系统架构,又要重点深入移动客户端的架构设计的方方面面,既要有跨平台思维,又要拿捏好原生和混合开发的尺度,另外移动应用的特点,导致移动架构师必须要比传统系统架构师更加注重非功能性的质量属性。
    7 前端架构师 这也是移动互联网的迅猛发展而细分出来的新的职责和岗位,这里的前端特指网站开发中的前端,主要考虑前端呈现层的设计(HTML/CSS/JS/AJAX/RIA/…),跨浏览器设计等等。
    8 ... ...


    3.  软件需求

    软件架构设计中常说需求驱动架构设计,可见需求在整个架构设计中起到了关键指引和方向的作用,如果以目标导向为原则,则需求的满足和实现就是架构设计的终极目标。
    OK,在进行架构设计之前,我们先看下软件需求。

    3.1.  软件需求怎么来的(软件需求的过程)

    阶段

    需求阶段

    说明

    什么人做什么事

    可能产生的文档

    客户方

    实施方

    客户方

    实施方

    1

    业务需求

    来自客户的原始需求,背景描述,业务诉求和期望目标。

    项目负责人或接口人描述需求或提供客户方需求文档。

    销售或售前接触客户,听取和记录需求。

    工作说明书(SOW),或邀标书

    售前的方案建议书

    2

    用户需求

    通常是在问题定义的基础上进行用户访谈、调查,对用户使用的场景进行整理,从而建立从用户角度的需求。

    项目负责人或接口人接受访谈和调研。

    需求分析师或项目经理等进行需求调研。

     

    调研计划、用户需求调研提问库、调研日志、用户需求说明书

    3

    软件需求

    从系统实现的角度描述的需求。开发人员(设计和分析人员)在业务需求、用户需求的基础上形成的。

     

    需求分析师或项目经理、架构师等讨论和细化需求,编写需求文档

     

    SRSSoftware Requirement Specification)软件需求规格说明书


    3.2.  软件需求的分类:

    另外,也有McCall软件质量模型:

    注:在架构设计中,对非功能性需求的重视程度,也会影响架构设计的好与劣;但也要平衡过渡设计和适可而止的关系。


    4.  软件架构的过程

    业界软件架构设计的方法论很多,各有各自的应用场景和特点,下文结合ADMEMS(Architecture Design Method has been Extended to Method System)架构设计方法论说明软件架构的过程:

    架构阶段

    目标

    方式方法

    现实工作场景

    预架构阶段

    全面理解需求;需求结构化,摒弃需求列表,建立二维需求观(ADMEMS矩阵)。

    使用ADMEMS矩阵方法,捋清需求间关系和发现衍生需求。

    1、与人:与项目经理、需求分析师等内部需求人员了解需求;与客户了解需求(不建议架构师做需求分析师角色)。
    2
    、与物:了解《需求规格说明书》等需求文档。"
    3
    、对需求有什么问题,反馈给售前或销售,可能会参与拜访客户或电话会议。
    4
    、销售或售前有时会要求提供一个大致的工作量,以便他们初步评估项目可行性。

    概念架构

    高层组件及其关系

    1、初步设计,基于关键功能,借助鲁棒图进行以发现职责为目的的初步设计(不是必须)。
    2
    、高层分割,将复杂系统切分为多个二级系统或多个子系统。
    3
    、考虑非功能需求,采用ADMEMS推荐的目标-场景-决策表。

    1、参与内部讨论:项目可行性分析、讨论,从需求、技术、人力、风险等角度提供建议。
    2
    、项目投标准备:参与投标团队的技术方案编写,编写系统架构章节,解决招标书上技术问题的问答。
    3
    、参与项目讲标:作为讲标团队成员参与项目讲标,负责技术问答环节的应对。

    细化架构

     

    5视图法

    在项目概要设计阶段,进行架构设计,制定规范和约定,为详细设计提供指导。

    实现

    详细设计
    编码实现

    架构设计形成详细设计文档

    在项目实现阶段,对开发人员提供规范指引和技术支持。


    注:架构设计的过程和内容的不是固定不变的,现实中,比如售前提供解决方案中,很多时候需要架构师提供细化架构中才会深思的逻辑架构、物理架构等,这时候,架构师就需要有螺旋思维和跳跃思维的方式,就像武功中,招式是死的,人是活的,要学会灵活运用。


    5.  软件架构设计的方式方法


    5.1.  多视图法


    多视图方法是业界广泛认同的一种架构设计思路,包括:
    ● SEI的3视图法:
    模块视图、组件-连接器视图、分配视图。
    ● 西门子的4视图法:
    概念视图、模块视图、代码视图、执行视图。
    ● RUP的4+1视图法:
    用例视图、逻辑视图、开发视图、进程视图、物理视图。
    ● 联邦企业架构框架:
    技术架构视图、信息架构视图、应用架构视图、业务架构视图。
    ● ……

    5.2.  5视图法


    5视图法分析的意义:

    ● 全面分析软件系统方方面面的问题
    ● 尽早地发现和排除项目风险与不确定因素
    ● 从不同角度去展现要设计的软件系统
    ● 为项目进行中不同的干系人提供指导:
        -- 逻辑架构描述系统功能,并指导系统测试
        -- 开发架构规范软件的层次及代码风格
        -- 数据架构指导数据库的设计
        -- 运行架构定义了一些关键过程的设计
        -- 物理架构明确软件如何部署与实施

    5.3.  5视图法设计步骤

    两种观念:

    观念

    设计步骤

    观念一

    顺序进行:

    1、逻辑架构。

    2、开发架构

    3、数据架构

    4、运行架构

    5、物理架构

    观念二

    5个视图是穿插进行设计的,对复杂系统而言,根本不可能将逻辑视图设计完了后再考虑其它视图。

    笔者观念

    观念一和观念二的情况在现实状况中都可能存在,要根据具体情况具体分析,但总体而言,5视图穿插进行思考更有利于思考的全局性和完整性。


    5.4.  如何进行5视图法的设计

    以下5视图表格中的工具和方法每个架构师或略有差异,以下仅为参考。

    5.4.1.  逻辑架构

    逻辑架构的重点是考虑软件功能性需求。

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    系统功能划分为几个子系统与功能模块?

    系统功能树

    树型结构图

     

    2

    向什么用户提供什么样的功能?

    用例模型

    UML用例图

    体现用户和行为

    3

    每个功能都是怎样的操作流程与分支?

    用例描述

    用例描述表

     

    含输入输出、事件流分析;

    不要有界面描述

    UML活动图

    进行业务流程分析,包括泳道图

    4

    如何通过界面与用户交互?怎样交互?

    鲁棒分析

    鲁棒图

    通过对“用例描述表”进行原文分析法拣出名词和动词

    5

    应当设计哪些类与界面?怎样设计?

    领域模型

    UML类图

     

    6

    与哪些外部系统接口?怎样接口?

    接口描述

    UML类图

     


    5.4.2. 开发架构

    开发架构重点关注的是开发编码实现方面的问题。

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    分层结构设计

    分层架构图(开发架构图)

    各种绘图工具

    好的分层结构支持自动化测试

    2

    开发技术选项

    开发语言

    开发框架

    开发工具

     

    考虑商用产品、开源框架、自研框架

    3

    模块划分

    源码工程;Project目录结构;

    分包(分库)

     

     

    4

    开发规范

    开发/编码规范文档;

     

     

    5

    软件质量属性

    分析和决策结果

     

    考虑运行期和开发期软件质量属性,并权衡利弊进行决策。

    5.4.3. 数据架构

    数据架构不仅仅要考虑开发中涉及到的数据库,实体模型,也要考虑物理架构中数据存储的设计。

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    数据是集中还是分布存储的?如何考虑分布式存储?

    数据架构图

     

     

    2

    领域模型到数据库表的转换?表结构关系的设计?

    逻辑模型

    物理模型

    ER

    Power Designer

    Visio

     

    3

    实体如何设计?充血模型和贫血模型?

    UML类图

     

     

    4

    使用什么数据库?关系型还是非关系型?

    选型结果

     

     


    关系型数据库

    非关系型数据库(NoSQL

    Oracle(首次发行:1980年)

    MySQL(首次发行:1995

    MS SQL Server(首次发行:1989

    PostgreSQL(首次发行:1989

    IBM DB2(首次发行:1983

    Microsoft Access(首次发行:1992

    Sybase ASE(首次发行:1987

    SQLite(首次发行:2000

    …… 

    MongoDB(首次发行:2009

    Cassandra(首次发行:2008

    Apache CouchDB

    Hbase

    Redis

    db4o

    BaseX

    …… 


    5.4.4. 运行架构

    运行架构关注的不再是全局而是局部,着重关注那些关键点与难点,常常需要技术攻关与预研。主要考虑控制流、通讯机制、资源争用、锁机制、同步异步、并发、串行,同时也要考虑质量属性。

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    运行:同步vs.异步;并发vs.串行

    考虑开发架构中代码的实现。

     

     

    2

    交互:对象间交互;状态转换

    考虑开发架构的合理性,到类、到接口、到代码。

     

     

    3

    质量:安全;可靠;可伸缩

    考虑开发架构的合理性

     

     

    4

    性能:响应时间;吞吐量

    估算:

    在线人数、并发人数;

    每秒事务量;

    响应时间。

     

     


    5.4.5. 物理架构

    物理架构主要考虑硬件选择和拓扑结构,软件到硬件的映射,软硬件的相互影响。

     

    考虑的方面

    产出物

    工具

    说明

    1

    网络方面:网络拓扑;网络设备;安全机制

    拓扑图

    安全规范

     

     

    2

    性能方面:可靠性、可伸缩性

    需要什么样设备性能

     

     

    3

    部署方面:集中式还是分布式;组件部署

    部署图

     

     

     


    6. 一个思考,谁驱动了架构设计?

    需求驱动了架构设计?

    质量属性了驱动了架构设计(ADD)?

    领域驱动了架构设计(DDD)?

    风险驱动了架构设计?

    质疑驱动了架构设计?

    ……

    到底是谁驱动了架构设计?我们以船舶设计建造为例,来看这些问题:

    目标和结果 à

    问题 à

    回答 à

    小结

    设计和制造一艘远洋货轮,能经历数月海上颠簸和长途跋涉,并保证货物的安全和完整,最后能顺利抵达目标港口。

    我们为什么要设计和制造这样的大船?

    市场有这个需求;

    获利很丰厚;

    解决就业;

    ……

    不管是外部需求还是内部的需求,都是需求。不正是需求驱动吗?

    如何保证货船能长途航行并经受波涛和风雨?

    船要造的结实;

    鲁棒性

    这些不正是质量属性驱动设计吗?

    引擎设计的强劲;

    性能

    船的燃料充足;

    持续可用性

    装备卫星电话、GPS、雷达等设备

    互操作性

    货物和人员要安全

    安全性

    船舶设计师怎么设计这样的船舶?

    现在都会通过计算机进行船舶的CAD3D模型设计。

    是不是佷似领域模型驱动了设计?

    造船一定有很多风险吧?

    那是,比如订货方客户有时提出改装船舶的意见(需求变化的风险);有时某些工艺成品率不稳定(质量风险);等等。

    所有可能的风险点在设计时都要考虑到,做好预案,才能保证架构设计的可行性和灵活性,风险驱动了架构设计。

    上面怎么提了那么多问题,其实还有很多问题,比如……

    嗯,你现在有不少疑问了。

    不断的质疑架构设计中可能存在各种问题,有质疑才有思考,才有解决方案,从而推动架构设计的不断完善。


    总结:

    以上几个方面都能驱动架构设计,并不是零和的规则,而是一个立方体从不同方向看的问题。以上方面有些是指导思想,有些是行动方式,有的兼而有之,阐述方式看似不同,终极目标还是造出大船(实现需求),造出好船(质量属性),怎么造(领域模型),造的顺利(风险控制),挑不出毛病(架构师自己先质疑问题并解决了)。


    7. 软件架构设计的误区

    ● 高开高走落不到实处

    ● 理想与现实需要折中

    ● 遗漏关键性约束与非功能需求

    ● 为虚无的未来埋单而过度设计

    ● 过早做出关键性决策

    ● 客户说啥就是啥成为酱油哥

    ● 埋头干活儿缺乏前瞻性

    ● 架构设计还要考虑系统可测性

    ● 架构设计不要企图一步到位


    8. 部分参考资料

    温昱的《一线架构师实践指南》

    展开全文
  • 软件架构设计的一些总结和理解

    万次阅读 多人点赞 2015-09-06 22:28:18
    1. 软件架构设计的What & Why ● 啥是软件架构(Software Architecture)? 软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统...

    1. 软件架构设计的What & Why

    ● 啥是软件架构(Software Architecture)?

    软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统的各个组件,组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

    软件架构设计就是从宏观上说明一套软件系统的组成与特性。

    软件架构设计是一系列有层次的决策 ,比如:功能与展现的决策;技术架构的决策;自主研发还是合作;商业软件还是开源软件 。

     

     

    为啥要进行软件架构设计?

    业务需求层出不穷;软件系统越来越复杂;参与的人越来越多;共性和特殊性的问题越来越多;技术发展日异月新;……

     

    2. 软件架构师

     

    2.1. 软件架构师是干什么的

     

    介于需求与开发的中间人     良好的沟通能力
    能够统领全局的大牛 良好的大局观
    能够将需求转换为技术     洞悉前沿与市场嗅觉
    能够为软件研发提供指导     见多识广的大牛
    需要全面思考软件系统方方面面的问题     缜密地思考问题
    能够攻关和搞定重要技术难题     公司可信赖的支柱

     

    2.2. 架构师的素质

     

    全局思维  

    从业务、市场,到技术实现;

    从软件的过去、现在,到将来;

    从外部客户,到内部研发;

    从软件研发,到硬件部署;

    从功能实现,到运行效率  

    战略思维  

    在所在行业的发展战略;

    在业务领域的发展战略;

    在技术方向的发展战略;

    在潜在市场的发展战略。

    前瞻思维  

    市场趋势的发展动向;

    前沿技术的发展动向;

    竞争对手的发展动向;

    合作伙伴的发展动向。

    抽象思维  

    各项业务需求:抽象成功能模块;

    各项功能的实现:抽象成软件架构。 

    逆向思维

    假如不实现会怎样?

    假如没搞定会怎样?

    假如没有它会怎样?

    假如被延期会怎样?

     

    2.3.  架构师的分类

    随着行业和社会的发展,架构师的定义和分类越来越广泛和细分,广泛和细分其实并不矛盾,如果“广泛”是x轴,“细分”是y轴,则二维坐标系x和y轴中间的任一点就是一种架构师类别。但总体来说,或目前来说,集合业界的大致认知,总结如下:

     

    No. 分类 描述
    1 解决方案架构师 与客户探讨业务需求,将业务、市场,与技术、产品结合起来,为客户提供解决他们需求的方案。
    2 系统架构师 也称应用架构师。最终确认和评估系统需求,并将业务转换为技术,为研发人员制订核心框架与技术规范 为研发工作澄清技术细节并扫清技术障碍 。
    3 平台架构师 这里的平台其实包括两个平台,一个是系统平台,也就是负责搭建多个系统整合的系统应用平台;另外一个其实是基础平台,是专门负责搭建基础技术平台;两者其 实区别蛮大,也经常容易被从业人员混乱。举个简单例子,金蝶有平台架构师一职,但是金蝶BOSS应用和金蝶中间件两者招聘的对象和技术要求是截然不同的。
    4 业务架构师 业务架构其实已经开始脱离技术层面了,但是它要求架构师有跨越多系统的大局观,去整合和组织不同系统的技术平台与交互模式。其实这个职位的未来也就是CIO了。
    5 网络架构师 过去,我们可能听的最多的是网络工程师。不错,一个优秀的网络架构师必须有足够的网络技术基底,并且它的关注点也是系统的基础架构。比如说如果搭建并优化集群环境,如果构建基于云计算的系统应用与部署等等。它对于像淘宝、腾讯这样的互联网公司是极其重要的。
    6 移动架构师 移动互联网的迅猛发展横向和纵向都细分出了很多新的职责和岗位,移动架构师的职责和作用日益重要,既要整体和全局考虑整个前后端的软件系统架构,又要重点深入移动客户端的架构设计的方方面面,既要有跨平台思维,又要拿捏好原生和混合开发的尺度,另外移动应用的特点,导致移动架构师必须要比传统系统架构师更加注重非功能性的质量属性。
    7 前端架构师

    这也是互联网的迅猛发展而细分出来的新的职责和岗位,这里的前端特指Web开发中的前端,主要考虑前端呈现层的设计(HTML/CSS/JS/AJAX/RIA/…),跨浏览器设计,性能优化等等。

    注:这些年,在很多互联网一线大厂,Web前端和移动客户端有融合为大前端的趋势和内在需求,所以,大前端架构师的知识领域和职责范围也有不同的涵盖和侧重。

    8 ... ...

     

    3.  软件需求

    软件架构设计中常说需求驱动架构设计,可见需求在整个架构设计中起到了关键指引和方向的作用,如果以目标导向为原则,则需求的满足和实现就是架构设计的终极目标。
    OK,在进行架构设计之前,我们先看下软件需求。

    3.1.  软件需求怎么来的(软件需求的过程)

     

    阶段

    需求阶段

    说明

    什么人做什么事

    可能产生的文档

    客户方

    实施方

    客户方

    实施方

    1

    业务需求

    高纬度抽象的需求,也是来自客户的原始需求,背景描述,业务诉求和期望目标。

    项目负责人或接口人描述需求或提供客户方需求文档。

    销售或售前接触客户,听取和记录需求。

    工作说明书(SOW),或邀标书

    售前的方案建议书

    2

    用户需求

    通常是在问题定义的基础上进行用户访谈、调查,对用户使用的场景进行整理,从而建立从用户角度的需求。

    项目负责人或接口人接受访谈和调研。

    需求分析师或项目经理等进行需求调研。

     

    调研计划、用户需求调研提问库、调研日志、用户需求说明书

    3

    软件需求

    从系统实现的角度描述的需求。开发人员(设计和分析人员)在业务需求、用户需求的基础上形成的。

     

    需求分析师或项目经理、架构师等讨论和细化需求,编写需求文档

     

    SRS(Software Requirement Specification)软件需求规格说明书

     

    3.2.  软件需求的分类:

     

    另外,也有McCall软件质量模型:

    注:在架构设计中,对非功能性需求的重视程度,也会影响架构设计的好与劣;但也要平衡过渡设计和适可而止的关系。

     

    4.  软件架构的过程

    业界软件架构设计的方法论很多,各有各自的应用场景和特点,下文结合ADMEMS(Architecture Design Method has been Extended to Method System)架构设计方法论说明软件架构的过程:

     

    架构阶段

    目标

    方式方法

    现实工作场景

    预架构阶段

    全面理解需求;需求结构化,摒弃“需求列表”,建立二维需求观(ADMEMS矩阵)。

    使用ADMEMS矩阵方法,捋清需求间关系和发现衍生需求。

    1、与人:与项目经理、需求分析师等内部需求人员了解需求;与客户了解需求(不建议架构师做需求分析师角色)。
    2、与物:了解《需求规格说明书》等需求文档。"
    3、对需求有什么问题,反馈给售前或销售,可能会参与拜访客户或电话会议。
    4、销售或售前有时会要求提供一个大致的工作量,以便他们初步评估项目可行性。

    概念架构

    高层组件及其关系

    1、初步设计,基于关键功能,借助鲁棒图进行以发现职责为目的的初步设计(不是必须)。
    2、高层分割,将复杂系统切分为多个二级系统或多个子系统。
    3、考虑非功能需求,采用ADMEMS推荐的目标-场景-决策表。

    1、参与内部讨论:项目可行性分析、讨论,从需求、技术、人力、风险等角度提供建议。
    2、项目投标准备:参与投标团队的技术方案编写,编写系统架构章节,解决招标书上技术问题的问答。
    3、参与项目讲标:作为讲标团队成员参与项目讲标,负责技术问答环节的应对。

    细化架构

     

    5视图法

    在项目概要设计阶段,进行架构设计,制定规范和约定,为详细设计提供指导。

    实现

    详细设计
    编码实现

    架构设计形成详细设计文档

    在项目实现阶段,对开发人员提供规范指引和技术支持。

     

    注:架构设计的过程和内容的不是固定不变的,现实中,比如售前提供解决方案中,很多时候需要架构师提供细化架构中才会深思的逻辑架构、物理架构等,这时候,架构师就需要有螺旋思维和跳跃思维的方式,就像武功中,招式是死的,人是活的,要学会灵活运用。

     

     

    5.  软件架构设计的方式方法

     

    5.1.  多视图法


    多视图方法是业界广泛认同的一种架构设计思路,包括:
    ● SEI的3视图法:
    模块视图、组件-连接器视图、分配视图。
    ● 西门子的4视图法:
    概念视图、模块视图、代码视图、执行视图。
    ● RUP的4+1视图法:
    用例视图、逻辑视图、开发视图、进程视图、物理视图。
    ● 联邦企业架构框架:
    技术架构视图、信息架构视图、应用架构视图、业务架构视图。
    ● ……

    5.2.  5视图法

    5视图法分析的意义:

    ● 全面分析软件系统方方面面的问题
    ● 尽早地发现和排除项目风险与不确定因素
    ● 从不同角度去展现要设计的软件系统
    ● 为项目进行中不同的干系人提供指导:
        -- 逻辑架构描述系统功能,并指导系统测试
        -- 开发架构规范软件的层次及代码风格
        -- 数据架构指导数据库的设计
        -- 运行架构定义了一些关键过程的设计
        -- 物理架构明确软件如何部署与实施

    5.3.  5视图法设计步骤

    两种观念:

     

    观念

    设计步骤

    观念一

    顺序进行:

    1、逻辑架构。

    2、开发架构

    3、数据架构

    4、运行架构

    5、物理架构

    观念二

    5个视图是穿插进行设计的,对复杂系统而言,根本不可能将逻辑视图设计完了后再考虑其它视图。

    笔者观念

    观念一和观念二的情况在现实状况中都可能存在,要根据具体情况具体分析,但总体而言,5视图穿插进行思考更有利于思考的全局性和完整性。

     

    5.4.  如何进行5视图法的设计

     

    以下5视图表格中的工具和方法每个架构师或略有差异,以下仅为参考。

    5.4.1.  逻辑架构

    逻辑架构的重点是考虑软件功能性需求。

     

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    系统功能划分为几个子系统与功能模块?

    系统功能树

    树型结构图

     

    2

    向什么用户提供什么样的功能?

    用例模型

    UML用例图

    体现用户和行为

    3

    每个功能都是怎样的操作流程与分支?

    用例描述

    用例描述表

     

    含输入输出、事件流分析;

    不要有界面描述

    UML活动图

    进行业务流程分析,包括泳道图

    4

    如何通过界面与用户交互?怎样交互?

    鲁棒分析

    鲁棒图

    通过对“用例描述表”进行原文分析法拣出名词和动词

    5

    应当设计哪些类与界面?怎样设计?

    领域模型

    UML类图

     

    6

    与哪些外部系统接口?怎样接口?

    接口描述

    UML类图

     

     

    5.4.2.  开发架构

     

    开发架构重点关注的是开发编码实现方面的问题。

     

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    分层结构设计

    分层架构图(开发架构图)

    各种绘图工具

    好的分层结构支持自动化测试

    2

    开发技术选项

    开发语言

    开发框架

    开发工具

     

    考虑商用产品、开源框架、自研框架

    3

    模块划分

    源码工程;Project目录结构;

    分包(分库)

     

     

    4

    开发规范

    开发/编码规范文档;

     

     

    5

    软件质量属性

    分析和决策结果

     

    考虑运行期和开发期软件质量属性,并权衡利弊进行决策。

     

    5.4.3.  数据架构

     

    数据架构不仅仅要考虑开发中涉及到的数据库,实体模型,也要考虑物理架构中数据存储的设计。

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    数据是集中还是分布存储的?如何考虑分布式存储?

    数据架构图

     

     

    2

    领域模型到数据库表的转换?表结构关系的设计?

    逻辑模型

    物理模型

    ER图

    Power Designer

    Visio

     

    3

    实体如何设计?充血模型和贫血模型?

    UML类图

     

     

    4

    使用什么数据库?关系型还是非关系型?

    选型结果

     

     

     

     

     

    关系型数据库

    非关系型数据库(NoSQL)

    Oracle(首次发行:1980年)

    MySQL(首次发行:1995)

    MS SQL Server(首次发行:1989)

    PostgreSQL(首次发行:1989)

    IBM DB2(首次发行:1983)

    Microsoft Access(首次发行:1992)

    Sybase ASE(首次发行:1987)

    SQLite(首次发行:2000)

    …… 

    MongoDB(首次发行:2009)

    Cassandra(首次发行:2008)

    Apache CouchDB

    Hbase

    Redis

    db4o

    BaseX

    …… 

     

     

     

    5.4.4.  运行架构

     

    运行架构关注的不再是全局而是局部,着重关注那些关键点与难点,常常需要技术攻关与预研。主要考虑控制流、通讯机制、资源争用、锁机制、同步异步、并发、串行,同时也要考虑质量属性。

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    运行:同步vs.异步;并发vs.串行

    考虑开发架构中代码的实现。

     

     

    2

    交互:对象间交互;状态转换

    考虑开发架构的合理性,到类、到接口、到代码。

     

     

    3

    质量:安全;可靠;可伸缩

    考虑开发架构的合理性

     

     

    4

    性能:响应时间;吞吐量

    估算:

    在线人数、并发人数;

    每秒事务量;

    响应时间。

     

     

     

     

     

    5.4.5.  物理架构

     

    物理架构主要考虑硬件选择和拓扑结构,软件到硬件的映射,软硬件的相互影响。

     

    考虑的方面

    产出物

    工具

    说明

    1

    网络方面:网络拓扑;网络设备;安全机制

    拓扑图

    安全规范

     

     

    2

    性能方面:可靠性、可伸缩性

    需要什么样设备性能

     

     

    3

    部署方面:集中式还是分布式;组件部署

    部署图

     

     

     

     

     

     

    6.  一个思考,谁驱动了架构设计?

     

    需求驱动了架构设计?

    质量属性了驱动了架构设计(ADD)?

    领域驱动了架构设计(DDD)?

    风险驱动了架构设计?

    质疑驱动了架构设计?

    ……

    到底是谁驱动了架构设计?我们以船舶设计建造为例,来看这些问题:

    目标和结果

    问题

    回答

    小结

    设计和制造一艘远洋货轮,能经历数月海上颠簸和长途跋涉,并保证货物的安全和完整,最后能顺利抵达目标港口。

    我们为什么要设计和制造这样的大船?

    市场有这个需求;

    获利很丰厚;

    解决就业;

    ……

    不管是外部需求还是内部的需求,都是需求。不正是需求驱动吗?

    如何保证货船能长途航行并经受波涛和风雨?

    船要造的结实;

    鲁棒性

    这些不正是质量属性驱动设计吗?

    引擎设计的强劲;

    性能

    船的燃料充足;

    持续可用性

    装备卫星电话、GPS、雷达等设备

    互操作性

    货物和人员要安全

    安全性

    船舶设计师怎么设计这样的船舶?

    现在都会通过计算机进行船舶的CAD和3D模型设计。

    是不是佷似领域模型驱动了设计?

    造船一定有很多风险吧?

    那是,比如订货方客户有时提出改装船舶的意见(需求变化的风险);有时某些工艺成品率不稳定(质量风险);等等。

    所有可能的风险点在设计时都要考虑到,做好预案,才能保证架构设计的可行性和灵活性,风险驱动了架构设计。

    上面怎么提了那么多问题,其实还有很多问题,比如……

    嗯,你现在有不少疑问了。

    不断的质疑架构设计中可能存在各种问题,有质疑才有思考,才有解决方案,从而推动架构设计的不断完善。

     

    总结:

     

    以上几个方面都能驱动架构设计,并不是零和的规则,而是一个立方体从不同方向看的问题。以上方面有些是指导思想,有些是行动方式,有的兼而有之,阐述方式看似不同,终极目标还是造出大船(实现需求),造出好船(质量属性),怎么造(领域模型),造的顺利(风险控制),挑不出毛病(架构师自己先质疑问题并解决了)。

     

     

    7.  软件架构设计的误区

     

    ● 高开高走落不到实处

    ● 理想与现实需要折中

    ● 遗漏关键性约束与非功能需求

    ● 为虚无的未来埋单而过度设计

    ● 过早做出关键性决策

    ● 客户说啥就是啥成为酱油哥

    ● 埋头干活儿缺乏前瞻性

    ● 架构设计还要考虑系统可测性

    ● 架构设计不要企图一步到位

     

     

    8.  部分参考资料

     

    温昱的《一线架构师实践指南》

     


    注:有网友问:这是自己总结,还是看书总结呢?
    我的回答是:看书是学习的过程,概念是不变真理,架构是工作内容,经验是多年积累,教训是切身体会,内容是自己总结,文章是自己码字,^_^。

    展开全文
  • 软件架构设计---软件架构概述

    万次阅读 2018-09-17 21:25:54
    通俗地讲,软件架构设计就是软件系统的“布局谋篇”。  人们在软件工程实践中,逐步认识到了软件架构的重要性,从而开辟了一个崭新的研究领域。软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构...

         像学写文章一样,在学会字、词、句之后,就应上升到段落,就应追求文章的“布局谋篇”,这就是架构。通俗地讲,软件架构设计就是软件系统的“布局谋篇”。

        人们在软件工程实践中,逐步认识到了软件架构的重要性,从而开辟了一个崭新的研究领域。软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架构评价和软件架构的形成方法等。

        软件设计人员学习软件架构知识旨在站在较高的层面上整体地解决好软件的设计、复用、质量和维护等方面的实际问题。

       1 软件架构概述 

        软件架构是软件抽象发展到一定阶段的产物,从编程的角度,可以清晰地看到软件抽象层次和表达工具的发展历史。

    • 20 世纪 60 年代是子程序的年代:出现了原始的软件架构,即子程序,并以程序间的调用为连接关系。

    • 20 世纪 70 年代是模块化的年代:出现了数据流分析、实体—关系图(E-R 图)、信息隐藏等工具和方法,软件的抽象层次发展到了模块级。

    • 20 世纪 80 年代是面向对象的年代:基于模块化的编程语言进一步发展成面向对象的语言,继承性地增加了一种新元素之间的连接关系。

    • 20 世纪 90 年代是框架的年代:标准的基于对象的架构以框架的形式出现了。如电子数据表、文档、图形图像、音频剪辑等可互换的黑箱对象,可以相互嵌入。

    • 当前(最近 10 年来):中间件和 IT 架构作为标准平台出现,用可购买可复用的元素来构建系统,同时,基于架构的开发方法和理论不断成熟。

    1  软件架构的定义 

        软件架构仍在不断发展中,还没有形成一个统一的、公认的定义,这里仅举出几个较权威的定义。

        定义 1:软件或计算机系统的软件架构是该系统的一个(或多个)结构,而结构由软件元素、元素的外部可见属性及它们之间的关系组成。

        定义 2:软件架构为软件系统提供了一个结构、行为和属性的高级抽象,由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式的约束组成。

        定义 3:软件架构是指一个系统的基础组织,它具体体现在:系统的构件,构件之间、构件与环境之间的关系,以及指导其设计和演化的原则上。(IEEE1471- 2000)

       前两个定义都是按“元素—结构—架构”这一抽象层次来描述的,它们的基本意义相同,其中定义 1 较通俗,因此,本章采用这一定义。该定义中的“软件元素”是指比“构件”更一般的抽象,元素的“外部可见属性”是指其他元素对该元素所做的假设,如它所提供的服务、性能特征等。

        为了更好地理解软件架构的定义,特作如下说明:

        (1)架构是对系统的抽象,它通过描述元素、元素的外部可见属性及元素之间的关系来反映这种抽象。因此,仅与内部具体实现有关的细节是不属于架构的,即定义强调元素的“外部可见”属性。

        (2)架构由多个结构组成,结构是从功能角度来描述元素之间的关系的,具体的结构传达了架构某方面的信息,但是个别结构一般不能代表大型软件架构。

        (3)任何软件都存在架构,但不一定有对该架构的具体表述文档。即架构可以独立于架构的描述而存在。如文档已过时,则该文档不能反映架构。

        (4)元素及其行为的集合构成架构的内容。体现系统由哪些元素组成,这些元素各有哪些功能(外部可见),以及这些元素间如何连接与互动。即在两个方面进行抽象:在静态方面,关注系统的大粒度(宏观)总体结构(如分层);在动态方面,关注系统内关键行为的共同特征。

        (5)架构具有“基础”性:它通常涉及解决各类关键的重复问题的通用方案(复用性),以及系统设计中影响深远(架构敏感)的各项重要决策(一旦贯彻,更改的代价昂贵)。

        (6)架构隐含有“决策”,即架构是由架构设计师根据关键的功能和非功能性需求(质量属性及项目相关的约束)进行设计与决策的结果。不同的架构设计师设计出来的架构是不一样的,为避免架构设计师考虑不周,重大决策应经过评审。特别是架构设计师自身的水平是一种约束,不断学习和积累经验才是摆脱这种约束走向自由王国的必经之路。

        在设计软件架构时也必须考虑硬件特性和网络特性,因此,软件架构与系统架构二者间的区别其实不大。但是,在大多情况下,架构设计师在软件方面的选择性较之硬件方面,其自由度大得多。因此,使用“软件架构”这一术语,也表明了一个观点:架构设计师通常将架构的重点放在软件部分。

        将软件架构置于商业背景中进行观察,可以发现软件架构对企业非常重要。

        (1)影响架构的因素。软件系统的项目干系人(客户、用户、项目经理、程序员、测试人员、市场人员等)对软件系统有不同的要求开发组织(项目组)有不同的人员知识结构、架构设计师的素质与经验、当前的技术环境等方面都是影响架构的因素。

    这些因素通过功能性需求、非功能性需求、约束条件及相互冲突的要求,影响架构设计师的决策,从而影响架构。

        (2)架构对上述诸因素具有反作用,例如,影响开发组织的结构。架构描述了系统的大粒度(宏观)总体结构,因此可以按架构进行分工,将项目组为几个工作组,从而使开发有序;影响开发组织的目标,即成功的架构为开发组织提供了新的商机,这归功于:系统的示范性、架构的可复用性及团队开发经验的提升,同时,成功的系统将影响客户对下一个系统的要求等。这种反馈机制构成了架构的商业周期。

    2 软件架构的重要性 

        从技术角度看,软件架构的重要性表现为如下几方面。

        (1)项目关系人之间交流的平台。软件系统的项目关系人分别关注系统的不同特性,而这些特性都由架构所决定,因此,架构提供了一个共同语言(公共的参考点),项目关系人以此作为彼此理解、协商、达成共识或相互沟通的基础。架构分析既依赖于又促进了这个层次上的交流。

        (2)早期设计决策。从软件生命周期来看,软件架构是所开发系统的最早设计决策的体现,主要表现为:

    • 架构明确了对系统实现的约束条件:架构是架构设计师对系统实现的各方面进行权衡的结果,是总体设计的体现,因此,在具体实现时必须按架构的设计进行。

    • 架构影响着系统的质量属性:要保证系统的高质量,具有完美的架构是必要的(虽然不充分)。

    • 架构可以用来预测系统的质量,例如,可以根据经验对该架构的质量(如性能)作定性的判断。

    • 架构为维护的决策提供根据。在架构层次上能为日后的更改决策提供推理、判断的依据。一个富有生命力的架构,应该是在最有可能更改的地方有所考虑(架构的柔性),使其在此点最容易进行更改。

    • 架构有助于原型开发。可以按架构构造一个骨架系统(原型),例如,在早期实现一个可执行的特例,确定潜在的性能问题。

    • 借助于架构进行成本与进度的估计。

        (3)在较高层面上实现软件复用。软件架构作为系统的抽象模型,可以在多个系统间传递(复用),特别是比较容易地应用到具有相似质量属性和功能需求的系统中。产品线通常共享一个架构。产品线的架构是开发组织的核心资产之一,利用架构及其范例进行多系统的开发,在开发时间、成本、生产率和产品质量方面具有极大的回报。基于架构的开发强调对各元素的组合或装配。系统开发还可以使用其他组织开发的元素,例如购买商业构件。

        (4)架构对开发的指导与规范意义不容忽略。架构作为系统的总体设计,它指导后续的详细设计和编码。架构使基于模板的开发成为可能,有利于开发的规范化和一致性,减少开发与维护成本。架构可以作为培训的基础,有利于培养开发团队和培训相关人员。

       从软件开发过程来看,如果采用传统的软件开发模型(生命周期模型),则软件架构的建立应位于概要设计之前,需求分析之后。

        基于架构的软件开发模型则明确地把整个软件过程划分为架构需求、设计、文档化、评审(评估)、实现、演化等 6 个子过程。本章各节将分别对这些子过程进行讨论。

    3 架构的模型

        软件架构作为一个有机的整体,可以分解成多个侧面来认识,每个侧面强调它的不同方面的特征,从而使架构设计师能整体地把握它的重点。我们可以将软件架构归纳成 5 种模型:结构模型、框架模型、动态模型、过程模型和功能模型。最常用的是结构模型和动态模型。

        (1)结构模型。这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接件和其他概念来刻画结构,并力图通过结构来反映系统的重要语义内容,包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是架构描述语言。

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

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

        (4)过程模型。过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。

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

        这 5 种模型各有所长,也许将 5 种模型有机地统一在一起,形成一个完整的模型来刻画软件架构更合适。即将软件架构视为这些模型的统一体,通过这些模型的表述(文档)来完整反映软件架构。例如,Kruchten 在 1995 年提出了一个“4+1”的视图模型。“4+1” 视图模型从 5 个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。每一个视图只关心系统的一个侧面,5 个视图结合在一起才能反映系统的软件架构的全部内容。“4+1”视图模型如图 9-1 所示。

        (1)逻辑视图:主要支持系统的功能需求,即系统提供给最终用户的服务。在逻辑视图中,系统分解成一系列的功能抽象,这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析,而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中,通过抽象、封装和继承,可以用对象模型来代表逻辑视图,用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格,逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。

        (2)开发视图:也称为模块视图,主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织,这样,对于一个软件系统,就可以由不同的人进行开发。开发视图要考虑软件内部的需求,如软件开发的容易性、软件的重用和软件的通用性,要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统输入输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发角度,也可以在确定每个元素之前,列出开发视图原则。

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

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

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

        希赛教育专家提示:逻辑视图和开发视图描述系统的静态结构,而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说,侧重的角度也有所不同。例如,对于管理信息系统来说,比较侧重于从逻辑视图和开发视图来描述系统,而对于实时控制系统来说,则比较注重于从进程视图和物理视图来描述系统。

    展开全文
  • LabVIEW软件架构设计

    热门讨论 2010-05-13 09:34:11
    LabVIEW软件架构设计LabVIEW软件架构设计LabVIEW软件架构设计LabVIEW软件架构设计LabVIEW软件架构设计
  • 移动端软件架构设计

    2020-05-18 19:11:35
    软件架构设计的关注点 软件架构设计应该关注 – 变化 软件架构设计的本质和目的 本质降低软件熵 目的:降低因需求增加导致的软件熵增加从而导致的成本增加 架构设计模式原则 架构的细节需要运用一些经典的设计...

    什么是架构

    • 软件架构是一张开发蓝图,是一个整体的规划,即软件工程的指导方针,软件开发的主要目标如图所示:
      在这里插入图片描述

    • 优秀的软件架构提供迅速响应,扩展灵活;还要具备美观性,代码要简洁,易于阅读、维护、能使维护者对功能产生更清晰的认识,能够快速地处理变化

    软件架构设计的关注点

    • 软件架构设计应该关注 – 变化

    软件架构设计的本质和目的

    • 本质降低软件熵
    • 目的:降低因需求增加导致的软件熵增加从而导致的成本增加

    架构设计模式原则

    • 架构的细节需要运用一些经典的设计模式原则,比较常用的原则之一为SOLID原则

    SOLID原则

    • 单一职责原则(SRP): 每一个类都应该只具有一种职责
    • 开放封闭原则(OCP) : 对于软件对象扩展是开放的,修改是封闭的,应该将统一的功能抽象成一个共有的接口,具体到每个对象中去实现
    • 里氏替换原则 (LSP) : 继承应该保证有关超类型对象的任何属性也适用于子类型对象
    • 依赖倒置原则 (ISP) : 程序要依赖抽象的接口而不要依赖具体的实现 – 面向接口编程
    • 接口分离原则 (DIP): 客户端不应该依赖于它不需要的接口或方法,类于类之间的依赖应该建立在最小的接口之上(接口不应该设计的过于臃肿而导致系统解耦困难,增加重构的复杂度)

    架构设计步骤

    1. 认识系统:认识系统的数据模型、业务组成、模块组成
    2. 设计系统:选择合适的架构模式,对架构模式调研分析,确定系统架构设计方案
    3. 创建系统:选择系统的实现环境,对系统进行部署,进入开发/改造阶段
    4. 收集反馈:系统创建完成,持续调研,收集反馈,对系统做下一步优化规划
    认识系统
    • 目标:
      • 设计者希望系统是什么?
      • 使用者希望系统是什么?
      • 成本预估目标如何?
    • 明确的问题
      • 现有系统存在的问题(内部)
      • 影响系统的外部条件是什么(外部)
    设计系统
    • 两个阶段
      • 技术选型
      • 架构模式选型
    • 注意的问题
      • 对于选定的技术和架构模式,团队学习成本和接受度如何
      • 选定的模型存在什么优势和劣势,团队成员对此情况的了解程度
      • 选定技术模型流行度如何,以及流行原因
    创建系统
    • 托管代码
    • 跟踪进度
    • 完成后进行复盘
    收集反馈
    • 代码评审
    • 匿名留言
    • 合作交流
    • 社区讨论
    展开全文
  • 软件架构设计师:软件架构风格

    千次阅读 2018-09-23 18:06:44
    软件架构设计的一个核心问题是能否使用重复的软件架构模式,即能否达到架构级别的软件重用。——基于这个目的,学者们开始研究和实践软件架构的风格和类型问题。  软件架构风格是描述某一特定应用领域中系统组织...
  • 软件架构设计---软件架构风格

    千次阅读 2018-09-17 21:33:52
     软件架构设计的一个核心问题是能否使用重复的软件架构模式,即能否达到架构级别的软件重用。也就是说,能否在不同的软件系统中,使用同一架构。基于这个目的,学者们开始研究和实践软件架构的风格和类型问题。  ...
  • 软件架构设计概述

    2019-05-04 17:15:06
    1、软件架构设计 软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架构评价和软件架构的形成方法等。 软件架构设计解决好软件的设计、复用、质量和维护等方面的实际问题;解决各类关键...
  • 微服务架构设计实践 目 次1 序言2 微服务3 软件架构设计思想4 微服务架构设计实践4.1 项目概述4.2 架构准备阶段4.3 概念架构阶段4.4 细化架构阶段4.4.1 业务架构4.4.2 数据架构4.4.3 应用架构4.4.4 技术架构4.4.5 ...
  • 软件架构设计 软件架构是软件抽象发展到一定阶段的产物,从编程的角度,可以清晰地看到软件抽象层次和表达工具的发展历史。 软件或计算机系统的软件架构是该系统的一个(或多个)结构,而结构由软件元素、元素的...
  • 绪论本文打算探讨一下软件架构设计的一些设计原则与经过实践验证的设计模式。 前端(MVC模式)和后端(接口层-业务层-助手层)的分层设计经过了几十年大量软件的证明。分层的思想,就是每一个层次专注做一件事情。每...
  •  软件属性包括功能属性和质量属性,但是,软件架构(及软件架构设计师)重点关注的是质量属性。因为,在大量的可能结构中,可以使用不同的结构来实现同样的功能性,即功能性在很大程度上是独立于结构的,架构设计师...
  • 题外话:本篇博客讲的是软件架构设计中的软件架构概念以及软件架构风格。由于软件架构风格包含的内容太多,在本篇博客中只讲一部分的架构风格,其余的放到下一篇博客中继续阐述。 一:软件架构的概念 1、软件架构...
  • 嵌入式系统软件架构设计

    千次阅读 2019-04-24 14:58:12
    嵌入式系统软件架构设计 目录 1.前言4 2.决定架构的因素和架构的影响4 2.1.常见的误解5 2.1.1.小型的系统不需要架构5 2.1.2.敏捷开发不需要架构7 3.嵌入式环境下软件设计的特点7 3.1.和硬件密切相关7 3.2...
  • 软件架构设计之七:软件架构设计

    千次阅读 2013-08-27 20:28:13
    一、本章要点 ...2)系统架构设计案例分析。包括软件架构技术、XML技术、基于架构的软件开发过程、架构模型(风格)、特定领域软件架构、基于架构的软件开发方法、架构评估、软件产品线、系统演化、设计
  • 软件架构设计的目的 对于外包业务类型的项目,软件架构设计的目的与产品类型的项目有所不同,在这里主要讨论外包类型项目的软件架构设计目的。 1、为大规模开发提供基础和规范,并提供可重用的资产,软件系统的大...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 28,895
精华内容 11,558
关键字:

软件架构设计