框架设计总结

框架设计总结

温昱老师的《一线架构师实现指南》读完好几天了,本书很多大牛都有推荐,自己从头到底一字不漏的看了,很多关键的方法,做了标记,看了多次,是一本介绍构架设计方面很好的书,准备把它做为工具书,在开始中用好其中的方法。

大学学的软件工程,软件设计要从需求分析、可行性分析、概要设计、软件设计、软件开发和测试,说的是一个大的过程,具体到针对一个项目时还是会感觉无从下手;本书提供的ADMEMS方法体系,把这一过程形成方法体系,让框架设计的操作性更强,四个核心主张:

1)       方法体系是大趋势。ADMEMS

2)       质疑驱动的架构设计。质疑“缺点儿什么”

3)       多阶段方法。多阶段多视图,提供了5视图方法。

4)       内置最佳实践的方法。ADMEMS中包括了10条经验、架构设计的整体思路、用鲁棒图进行初步设计、矩阵方法、约束的四大类型。。。

ADMEMS(Architectural Design Method has been Extended to Method System)架构设计方法已扩展到方法体系,主要包括:3个阶段,1个贯穿环节,

作者:pyy

目录

1. 预备架构(Pre-architecture)阶段(简称PA阶段).......................................... 2

2. 概念架构(Conceptual-architecture)阶段(简称CA阶段)............................. 6

1.1. 初步设计....................................................................................................... 7

1.2. 高层分割....................................................................................................... 9

1.3. 考虑非功能需求......................................................................................... 11

3. 细化架构(Refined-architecture)阶段(简称RA阶段)................................. 12

3.1. 逻辑架构..................................................................................................... 13

1. 先从划分子系统的3种必用手段讲起................................................ 13

2. 逻辑架构设计的10条经验要点.......................................................... 16

3. 逻辑架构设计中设计模式应用............................................................ 17

4. 贯穿案例................................................................................................ 17

3.2. 物理架构、运行架构、开发架构............................................................. 19

1. 物理架构视图........................................................................................ 19

2. 运行架构视图........................................................................................ 20

3. 开发架构视图........................................................................................ 21

4. 贯穿案例................................................................................................ 22

1.   预备架构(Pre-architecture)阶段(简称PA阶段)

概括为一句话:全面理解需求;提供明确的以ADMEMS矩阵为核心的“四步法”:

1)       需求结构化

2)       分析约束影响

3)       确定关键质量

4)       确定关键功能

矩阵方法,二维需求表如下,从各角度分析需求

银行系统示例

需求层次——需求方面矩阵,要考虑的要素

2.   概念架构(Conceptual-architecture)阶段(简称CA阶段)

重大需求塑造概念架构,概念架构满足“架构=组件+交互”的基本定义,只不过更改关注高层组件,不应涉及接口细节.

三个步骤:

1.       初步设计,借助鲁棒图进行以发现职责为目的的初步设计

2.       高层分割,对系统这个墨盒进行高层切分,例如切分为多个二级系统,或者直接切分为具体子系统。

3.       考虑非功能需求,使用目标-场景-决策表.

1.1.         初步设计

鲁棒图,下图所示的三个要素,进行表示

10条经验

1)       守建模原则

2)       简化建模语言

3)       宁3种元素的发展思路

4)       增量建模

5)       实体对象#持久化对象

6)       只对关键功能(用例)画鲁棒图

7)       每个鲁棒图有2-5个控件对象

8)       勿关细节

9)       勿过分关注UI,除非是辅助或验证UI设计

10)   鲁棒图#用例规约的可视化

例子:

.1.2.      高层分割

二种套路:切系统为系统,切系统为子系统

切系统为系统是指

系统比较复杂,须要进行两组高层切分.

首先把系统切成更小一级的系统,每个更小一级的系统都可以有单独的需求,设计,实现。。。

之后,针对每个“更小一级的系统”进行“切系统为子系统”

示例:

切系统为子系统,最常见的方式就是分层,PM系统示例

4层架构方式

分层有不同的角度,而且互相不矛盾。

① Layer:逻辑层

重视职责的划分,职责之间常常是上层使用下层的关系——但是根本不关心上层和下层是否“能分布”在不同的机器上,如:

② Tier:物理层

③ 按通用性分层

④ 技术堆叠

1.3.考虑非功能需求

非功能需求往往非常笼统,而场景是一种明确性很强的技术,目标-场景-决策表可以让架构师理性地应对非功能需求。

如下表


目标


场景


决策


可重用性


欲嵌入的HIS系统种类较多,如何避免开发多个完全独立的“医生工作站嵌入单元”


研究可能嵌入的HIS,确定“医生工作站嵌入单元”的不变部分和可变部分。。。


。。。


。。。


。。

3.   细化架构(Refined-architecture)阶段(简称RA阶段)

Refined-architecture是相对Conceptual-architecture而言的,它们是架构设计的两个层次,分别对于“概念级”解决方案和“规约级”解决方案,Refined-architecture属于架构设计,不能与Detailed Design(详细设计)相混淆。

使用工具:多视图方法。

工具说明:

5视图方法


视图


思维立足点


技术关注点


逻辑视图


职责划分


职责划分

逻辑层

子系统、模块

关键类

职责间协作

接口

协作关系


开发视图


程序单元组织


程序单元

源文件、配置文件

程序库、框架

目标单元

程序单元组织

project划分

Project目录结构

编译依赖关系


运行视图


控制流组织


控制流

进程、线程

中断服务程序

控制流组织

系统启动与停机

控制流通信

加锁与同步


物理视图


物理节点组织


物理节点

PC、服务器

单片机、单板机、专用机

软件安装、部署、烧写

系统软件选型

物理节点拓扑

连接方式、拓朴结构

物理层

冗余考虑


数据视图


持久化设计


持久数据单元

文件

关系数据库

实时数据库

数据存储格式

文件格式

数据库Schema

3.1.         逻辑架构

1.     先从划分子系统的3种必用手段讲起

分层的细化


展现层


控制层


业务接口层


业务实现层


业务实体层


数据访问层

分区的引入

开发应该“深度优先”,而不是“广度优先”,分区是一种单元,它位于某个层的内部,其粒度比层小。

机制的提取

基于接口(和抽象)的协作是机制,基于具体类的协作则算不上机制。机制是一种特殊的子系统,

3个手段是相辅相成的关系。

划分子系统的4个重要原则

²  职责不同的单元划分归不同的子系统

²  通用性不同的单元划归不同的子系统

²  需要不同开发技能的单元划归不同子系统

²  兼顾工作量的相对均衡,进一步切分太大的子系统。

接口设计的事实与谬误

“分”是手段,“合”是目的,不能“合”在一起支持更高层功能的模板,又有何用?

协作决定接口,“我的接口我做主”的观点是错误的,

逻辑架构设计的整体思维套路

²  质疑驱动(功能方面(特殊功能支持吗?),质量方面(耦合性、重用性、性能。。。))

²  结构设计和行为设计相分离

示例:

增量建模技巧——不要急于“一口吃成个胖子”

2.     逻辑架构设计的10条经验要点

1)       划分子系统:分层的细化

2)       划分子系统:分区的引入

3)       划分子系统:机制的提取

4)       接口的定义:协作决定接口

5)       选用序列图:杜绝协作图

6)       包-接口图:从结构到待办的桥

7)       灰盒包图:描述关键子系统

8)       循序渐进的螺旋思维

9)       设计模式:包内结构

10)   设计模式:包间协作

3.     逻辑架构设计中设计模式应用

明确子系统内的结构

明确包间的协作关系

4.     贯穿案例

PASS系统的架构设计

首先应该注意二点,第一,细化架构设计的重要“输入”之一是概念架构设计,不应忽视。下图列出了“基于鲁棒图的初步设计”和进行高层分割考虑后的图

第二,5视图方法的应用,总体而言是5个视图的设计穿插进行的。

从结构设计到行动设计,常用手段是画序列图,如下图所示

有了不同职责单元之间具体的协作关系,就可以展开细致的“质疑”了——别忘了,架构设计是质疑驱动的

3.2.         物理架构、运行架构、开发架构

1.     物理架构视图

着重考虑运行软件的计算机、网络、硬件设施等情况,关注如何配置硬件和网络来满足系统的可靠性、可伸缩性、持续可用性、性能、完全性等方面的要求。3项任务:

硬件选择与物理拓扑

软件到硬件的映射关系

方案的优化

物理架构的设计内容。

物理架构节点

PC 、服务器

单片机、单板机、专用机

软件安装、部署、烧写

系统软件造型

物理节点拓扑

连接方式、拓扑结构

物理层

冗余考虑

2.     运行架构视图

工作内容:

确定引入哪些控制流

确定每条控制流的任务

处理相关问题:控制流的创建、销毁、通信机制等

进一步考虑:控制流之间的同步关系,若有资源争用还要引入加锁机制

运行架构的设计内容

控制流

进程、线程

中断服务

控制流组织

系统启动与停机

控制流通信

加锁与同步

在实践中最常用于实现控制流的手段有3种

进程

线程

中断服务程序

3.     开发架构视图

完成下列工作

将“逻辑职责”映射为“程序单元”

要自主编写的源程序

可重用的库、框架

其他方式(如Shell脚本、平台支持下的配置文件)

开发技术选型

开发语言

开发工具

“程序单元”间关系

project划分(可选)

Project目录结构

编译依赖关系

4.     贯穿案例

时间: 2024-10-13 17:49:35

框架设计总结的相关文章

静态网页框架设计首次体验(文章改)

根据教材与上网成功解决了Tomcat与Myeclipse的安装,同时熟悉了Java web创建项目到部署运行整个过程.今天起正式开始学习有关Java web的编程部分.Java web静态网页(HTML网页)的标记含义.基本语法的介绍到框架设计基本模板与案例,今天的学习的内容,让网页编程有了一个初步的框架.结合自身所在协会的情况,计划制作一个关于协会的网页,已有初步想法,望通过学习不断完善和修改协会网站.根据今天所学,并参考书本30页框架设计案例对网页进行初步搭建. 具体代码如下 TW.jsp:

Linux设备驱动框架设计

引子 Linux操作系统的一大优势就是支持数以万计的芯片设备,大大小小的芯片厂商工程师都在积极地向Linux kernel提交设备驱动代码.能让这个目标得以实现,这背后隐藏着一个看不见的技术优势:Linux内核提供了一套易于扩展和维护的设备驱动框架.Linux内核本身提供一套设备驱动模型,此模型提供了Linux内核对设备的一般性抽象描述,包括设备的电源管理.对象生命周期管理.用户空间呈现等等.在设备模型的帮助下,设备驱动开发工程师从设备的一般性抽象中解脱出来.但是每个设备的具体功能实现还需要大量

JS读书笔记:《JavaScript框架设计》——第12章 异步处理

一.何为异步   执行任务的过程可以被分为发起和执行两个部分. 同步执行模式:任务发起后必须等待直到任务执行完成并返回结果后,才会执行下一个任务. 异步执行模式:任务发起后不等待任务执行完成,而是马上执行下一个任务,当任务执行完成时则会收到通知. 面对IO操作频繁的场景,异步执行模式可在同等的硬件资源条件下提供更大的并发处理能力,也就是更大的吞吐量. 但由于异步执行模式打破人们固有的思维方式,并且任务的发起和任务的执行是分离的,从而提高编程的复杂度. 多线程.多进程均可实现异步模式. 二.从回调

WisDom.Net 框架设计(七) 验证框架

WisDom.Net-验证框架 1.分类 这里我们将数据验证分为以下几种 数据类型校验      主要用于确保数据类型输入的正确  比如年龄一项输入 A岁 ,显然不合法 域检查               主要用于验证输入的数据的是否在取值范围  比如在年龄一项 输入 400 ,显然这里不合法 格式检查            主要用于检查数据格式是否正确, 比如Email 输入Ca 显然这里也是不合法 自定义检查,       自定义校验数据. 比如 校验数据格式是否合法等 2.简介      

WisDom.Net 框架设计(五) 权限设计

WisDom.Net --权限设计 1.需求分析     基本在所有的管理系统中都离不开权限管理.可以这么说,权限管理是管理系统的核心所在. 权限管理说白一些就是每个人能够做什么,不能够做什么.可以说是一套规则.下面就说一下,在wisdom.net中的权限     1. 控制用户修改和删除数据.即 用户编辑和删除自己创建的数据,但是只能编辑和删除比自己权限小的人创建的数据     2. 模块的控制. 用户只能访问自己被授权访问的模块,不能访问其他模块     3. 用户被赋予不同的角色,各个角色

WisDom.Net 框架设计(四)

WisDom.Net  ----用户安全 1.用户单机登录 正如其名这里要求其实就是显示用户只能在一台电脑上登录.防止多处登录,这里简单的说一下实现原理,我们在这里使用session +cookie 的方法来实现  如下图所示 (1) 输入用户名密码 (2) 校验用户名密码格式是否正确 (3) 传入用户名密码 (4) 校验用户密码是否正确,返回登录LoginGuid (5) 用户名密码是否正确 (6) 判断用户在session中是否存在,存在即更新用户LoginGuid,不存在则新增,并在coo

游戏UI框架设计(三) : 窗体的层级管理

游戏UI框架设计(三) ---窗体的层级管理 UI框架中UI窗体的"层级管理",最核心的问题是如何进行窗体的显示管理.窗体(预设)的显示我们前面定义了三种类型: 普通.隐藏其他.反向切换.代码如下: "普通显示"模式允许多个窗体同时显示,这种类型应用最多.例如RPG中的主城界面(见下图). "隐藏其他界面" 模式一般应用于全局性的窗体.我们在开发此类窗体时,为了减少UI渲染压力.提高Unity渲染效率,则设置被覆盖的窗体为"不可见&qu

niubi-job:一个分布式的任务调度框架设计原理以及实现

niubi-job的框架设计是非常简单实用的一套设计,去掉了很多其它调度框架中,锦上添花但并非必须的组件,例如MQ消息通讯组件(kafka等).它的框架设计核心思想是,让每一个jar包可以相对之间独立的运行,并且由zk辅助进行集群中任务的调度. 接下来,咱们就一步一步的来看下niubi-job整个的框架设计与实现. 框架设计概述 讲解之前,让我们先来看一张niubi-job的框架设计图.如下: 可以看到,该图的结构非常简单,只有四个部分组成. web控制台:负责发布任务,监控任务的状态信息,上传

基于SEDA的异步框架设计与实现

基于SEDA的异步框架设计与实现 二.为什么使用SEDA 目前,面对并发环境,主流互联网服务器编程模型有两种:多线程模型以及事件驱动模型.但是这两个模型都不足以解决这个问题.我们来首先看一下这两种编程模型. 1.多线程并发模型 多线程并发模型是目前最普遍的服务器编程模型,该模型的架构如下图所示:        该模型针对每一个请求,会为其创建并分配一个线程.该线程负责这个请求的处理.该模型的优点:执行粒度是整个完整的处理流程.处理逻辑清晰,容易开发.但与此同时缺点也很明显:如果处理过程中某一步骤

Entity Framework 实体框架的形成之旅--Code First的框架设计(5)

在前面几篇介绍了Entity Framework 实体框架的形成过程,整体框架主要是基于Database First的方式构建,也就是利用EDMX文件的映射关系,构建表与表之间的关系,这种模式弹性好,也可以利用图形化的设计器来设计表之间的关系,是开发项目较多采用的模式,不过问题还是这个XML太过复杂,因此有时候也想利用Code First模式构建整个框架.本文主要介绍利用Code First 来构建整个框架的过程以及碰到的问题探讨. 1.基于SqlServer的Code First模式 为了快速