系统分析师--05系统设计_behavorial modelling 系统分析-优快云博客

本文链接：https://blog.youkuaiyun.com/bugnotfound/article/details/145605579

5.系统设计

处理流程设计

业务流程建模

标杆瞄准
IDEF(一系列建模、分析和仿真方法的统称)
DEMO(组织动态本质建模法)
Petri网
业务流程建模语言
基于服务的BPM

IDEF

IDEF0:业务流程（功能）建模
IDEF1:信息建模
IDEF1X:数据建模（如ER模型）
IDEF2:仿真建模设计
IDEF3:过程描述获取
IDEF4:面向对象设计
IDEF5：本体论描述获取
IDEF6：设计原理获取
IDEF7：信息系统审计
IDEF8:用户界面建模
IDEF9:场景驱动信息系统设计
IDEF10:实施架构建模
IDEF11：信息制品建模
IDEF12:组织结构建模
IDEF13:三模式映射设计
IDEF14:网络规划

软件架构设计

软件架构的概念

架构设计就是需求分配，即将满足需求的职责分配到组件上

软件架构风格是描述某一特定应用领域中系统组织方式的管用模式。架构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的
软件架构为软件提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述，这些元素的相互作用，指导元素集成的模式以及这些模式的约束组成
软件架构是项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性
软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础
软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量

软件架构风格

架构设计的一个核心问题是能否达到架构级的软件复用
架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统
架构风格定义了用于描述系统的术语表和一组指导构件系统的规则
数据流风格：批处理序列、管道-过滤器
调用/返回风格：主程序/子程序、面向对象、层次结构
独立构件风格：进程通信、事件驱动系统（隐式调用）
虚拟机风格：解释器、基于规则的系统
仓库风格：数据库系统、超文本系统、黑板系统

结构化设计

概要设计，详细设计

抽象化
自顶相下、逐步求精
信息隐蔽
模块独立（高内聚、低耦合）

保持模块的大小适中
尽可能减少调用的深度
多扇入，少扇出
单入口，单出口
模块的作用域应该在模块之内
功能应该是可预测的

面向对象设计

基本过程

面向对象设计

设计原则

单一职责原则：设计目的单一的类
开放-封闭原则：对扩展开放，对修改封闭
李氏替换原则：子类可以替换父类
依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程
接口隔离原则：使用多个专门的接口比使用单一的总接口要好
组合重用原则：要尽量使用组合，而不是继承关系达到重用目的
迪米特原则（最少知识法则）：一个对象应当对其他对象有尽可能少的了解

设计模式的概念

架构模式
- 软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策
设计模式
- 主要关注软件系统的设计，与具体的实现语言无关
惯用法
- 是最底层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式，即语言的惯用法。列如引用-计数就是C++语言中的一种惯用法

设计模式的分类

创建型模式
- 工厂方法模式
- 抽象工厂模式
- 原型模式
- 单例模式
- 构件器模式
结构性模式
- 适配器模式
- 桥接模式
- 组合模式
- 装饰模式
- 外观模式
- 享元模式
- 代理模式
行为型模式
- 职责链模式
- 命令模式
- 解释器模式
- 迭代器模式
- 中介者模式
- 备忘录模式
- 观察者模式
- 状态模式
- 策略模式
- 模板方法模式
- 访问者模式

创建型模式

创建性模式

结构型模式

结构性模式

行为型模式

行为性模式1

人机界面设计

置于用户控制之下
- 以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
- 提供灵活的交互
- 允许用户交互可以被中断和撤销
- 当技能级别增加时可以使交互流水化并允许定制交互
- 使用户隔离内部技术细节
- 设计应允许用户和出现在屏幕上的对象直接交互
减少用户的记忆负担
- 减少对短期记忆的要去
- 建立有意义的缺省
- 定义直觉性的捷径
- 界面的视觉布局应该基于真实世界的隐喻
- 以不断进展的方式揭示信息
保持界面的一致性
- 允许用户将当前任务放入有意义的语境
- 在应用系列内保持一致性
- 如过去的交互模型已建立起了用户期望，除非有迫不得已的理由不要改变它

web应用设计

从架构来看
- MVC,MVP,MVVM,REST,Webservice，微服务
从缓存来看
- MemCache，Redis，Squid
从并发分流来看
- 集群（负载均衡），CDN
从数据库来看
- 主从库（主从复制），内存数据库，反规范化技术，NoSQL，分区（分表）技术，视图与物化视图
从持久化来看
- Hidernate，Mybatis
从分布存储来看
- Hadoop，FastDFS，区块链
从数据编码来看
- XML,JSON
从Web应用服务器来看
- Apache，WebSphere，WebLogic，Tomcat,JBOSS,IIS
其它
- 静态化，有状态与无状态，响应式Web设计

单台机器到数据库与web服务器分离

应用服务器集群

系统演变到这里，将回出现以下问题

用户的请求由谁来转发到具体的应用服务器
如果没测访问到的服务器不一样，那么如何维护seesion

解决问题：负载均衡，有无状态问题

负载均衡的引入

负载均衡技术

基于特定软件的负载均衡（HTTP重定向）（应用层）
反向代理负载均衡（应用层）
基于DNS的负载均衡（传输层）
基于NAT的负载均衡（传输层）
混合型负载均衡
静态算法：
- 轮转算法、加权轮转算法、源地址哈希散列算法、目标地址哈希散列算法、随机算法
动态算法
- 最小连接数算法、加权最小连接数算法、加权百分比算法
硬件负载均衡
- F5
软件负载均衡
- LVS,Nginx，HAproxy

应用层负载均衡

http重定向
- HTTP重定向就是应用层的请求转发。用户的请求其实已经到了HTTP重定向负载均衡服务器，服务器根据算法要去用户重定向，用户收到重定向请求后，在次请求真正的集群
- 特点：实现简单，但性能较差
反向代理服务器
- 在用户的请求到达反向代理服务器时（已经到达网站机房），由反向代理服务器根据算法转发到具体的服务器，常用的apache，nginx都可以充当反向代理服务器
- 特点：部署简单，但代理服务器可能成为性能的瓶颈

传输层负载均衡

DNS域名解析负载均衡
- DNS域名解析负载均衡就是在用户请求DNS服务器，获取域名对应的IP地址时，DNS服务器之间给出负载均衡后的服务器IP
- 特点：效率比HTTP重定向搞，减少维护负载均衡服务器成本，但一个应用服务器故障，不能及时通知DNS，而且DNS负载均衡的控制权在域名服务器商那里，网站无法做出更多的改善和更强大的管理
基于NAT的负载均衡。基于NAT的负载均衡将一个外部IP地址映射为多个IP地址，对每次连接请求动态地转换为一个内部节点的地址
- 特点：技术较为成熟，一般在网关位置，可以通过硬件实现，像四层交换机一般就采用了这种技术

有状态与无状态

无状态服务
- 对单词请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息
有状态服务
- 与无状态服务相反，它回在自身保存一些数据，先后的请求是有关联的

数据库读写分离化

用缓存缓解读库的压力

CDN（内容分发网络）

CDN的全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快，更稳定

XML与JSON

XML

扩展标记语言XML，用于标记电子文件使其具有结构性的标记语言，可以用来标记数据，定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言

XML的优点
- 格式统一，符合标准
- 容易与其他系统进行远程交互，数据共享比较方便
XML的缺点
- XML文件庞大，文件格式复杂，传输占带宽
- 服务器端和客户端都需要花费大量代码来解析XML，导致服务器端和客户端代码变得异常复杂且不易维护
- 客户端不同浏览器之间解析XML的方式不一致，需要重复编写很多代码
- 服务器端和客户端解析XML花费较多的资源和时间

JSON

JSON是一种轻量级的数据交换格式，具有良好的可读和便于快速编写的特性。可在不同平台进行数据交换

JSON的优点
- 数据格式比较简单，易于读写，格式都是压缩的，占用带宽小
- 易于解析，客户端JS可以简单通过eval()进行JSON数据的读取
- 支持多种语言，包括ActionScript，C,C#,ColdFusion，java，javascript，perl，php，python，ruby等服务器端语言，便于服务器端的解析
- 因为JSON格式能直接为服务器端代码使用，大大简化了服务器端和客户端的代码开发量，且完成任务不变，并且易于维护
JSON的缺点
- 没有XML格式那么推广的深入人心和喜用广泛，没有XML那么通用性

Web应用服务器

两层含义

WEB服务器：其职能较为单一，就是把浏览器发过来的Request请求，返回html页面
应用服务器：进行业务逻辑的处理

Apache
- Web服务器，市场占有率达60%左右，它可以运行在几乎所有的Unix，Windows，Linux系统平台上
IIS
- 早期WEB服务器，目前小规模站点仍有应用
Tomcat
- 开源，运行servlet和JSP Web应用软件的基于Java的Web应用软件容器
JBOSS
- JBOSS是基于J2EE的开放源代码的应用服务器，一般与Tomcat或Jetty绑定使用
WebSphere
- 一种功能完善、开放的Web应用程序服务器，它是基于Java的应用环境，用于建立，部署和管理Internet和Intranet Web应用程序
WebLogic
- BEA WebLogic Server 是一种多功能，基于标准的web应用服务器，为企业构建自己的应用提供了坚实的基础
Jetty
- Jetty是一个开源的servlet容器，它为基于Java的web容器

缓存技术

MemCache
- Memcache是一个高性能的分布式的内存对象缓存系统，用于动态Web应用以减轻数据库负载。Memcache通过在内存里维护一个统一的巨大的hash表，它能够用来存储各种格式的数据，包括图像，视频，文件以及数据库检索的结果等
Redis
- Redis是一个开源的使用ANSI C语言编写，支持网络，可基于内存亦可持久化的日志型，Key-Value数据库，并提供多种语言的API
Squid
- Squid是一个高性能的代理缓存服务器，Squid支持FTP,gopher，HTTPS和HTTP协议。和一般的代理缓存软件不同，Squid用一个单独的，非模块化的，I/O驱动的进程来处理所有的客户端请求

Redis与Memcache的差异

Redis和Memcache都是将数据存放在内存中，都是内存数据库。他们都支持key-value数据类型。同时Memcache还可用于缓存其他东西，列如图片，视频等等，Redis还支持list，set，hash等数据结构的存储
Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以在次加载进行使用。Memcache挂掉后，数据不可恢复，Redis数据丢失后可以恢复
灾难恢复-Memcache挂掉后，数据不可恢复，Redis数据丢失后可以恢复
在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcache相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的calue交换到磁盘
Redis在很多方面支持数据库的特性，可以这样说他就是一个数据库系统，而Memcache只是简单地K/V缓存

所以在选择方面如果有持久方面的需求或对数据类型和处理有要求应该选择Redis。
如果简单的key/value存储应该选择Memcache