【学习笔记】软件架构与需求分析方法

本文详细介绍了软件架构的体系,包括系统与子系统、模块、组件和服务的概念,并探讨了架构原则如解耦、分层和封装。接着,文章阐述了架构的方法,涵盖业务架构、功能架构、系统架构等多个方面,并分析了架构的演进路径,从单体架构到分布式架构再到微服务架构。此外,文章还强调了服务化的重要性及其好处和问题。最后,文章深入探讨了需求分析的常见问题,如需求不明确、理解不一致和需求变动,并详细讲解了需求获取的步骤和要素。案例部分以电商订单系统为例,展示了角色、场景、功能和流程的分析过程。
摘要由CSDN通过智能技术生成

目录

1.软件架构体系

1.1 系统与子系统

1.2 模块、组件、服务

1.3 软件架构体系

 2. 架构原则

2.1 解耦

2.2 分层

2.3 封装

3. 架构的方法

3.1 业务架构

3.2 功能架构图

3.3 系统架构

3.4 技术架构

3.5 数据架构

3.6 部署架构

 4. 架构的演进之路

 4.1 单体架构

 4.2 分布式架构

4.2.1 应用集群

4.2.2 分布式缓存

4.2.3 业务拆分

4.2.4 分库分表和读写分离

4.2.5 静态化和CDN

4.2.6 异步解耦

4.3 微服务架构

5. 服务化

5.1 为什么需要服务化

5.2 服务化的好处

5.3 服务化的问题

6. 常见的需求问题

6.1 需求不明确

6.2 需求理解不一致

6.3 需求自身经常变动

7. 需求获取

 7.1 需求来源

 7.2 需求分类

 7.3 获取步骤

 8. 需求要素

8.1 角色场景

8.2 业务流程

8.3 数据实体

8.4 功能性需求

8.5 非功能性需求

9. 案例:电商订单系统

9.1 概述

9.2 角色

9.3 场景(用例)

9.4 功能

9.5 实体

9.6  流程

1.软件架构体系

1.1 系统与子系统

系统:泛指由-群有关联的个体组成,根据某种规则运作,能完成个别元件不能单独完成的工作的群体。
        ●关联:系统是由一群有关联的个体组成的,没有关联的个体堆在一 起不能成为一个系统。例如,把-个汽车发动机和一堆苹果放在一起不能称之为一-个系统,把发动机、底盘、轮胎、车架组合起来才能成为一台汽车,构成一个系统。
        ●规则:系统内的个体需要按照指定的规则运作,而不是单个个体各自为政。规则规定了系统内个体分工和协作的方式。例如,汽车发动机负责产生动力,然后通过变速器和传动轴,将动力输出到车轮上,从而驱动汽车前进。
        ●能力:系统能力与个体能力有本质的差别,系统能力不是个体能力之和,而是产生了新的能力。例如,汽车能够载重前进,而发动机、变速器、传动轴、车轮本身都不具备这样的能力。
子系统:子系统也是由一群有关联的个体所组成的系统,多半会是更大系统中的一部分。子系统的定义和系统定
义是一样的,只是观察的角度有差异,一个系统可能是另外-个更大系统的子系统。
以微信为例来做一个分析:
        ●微信本身是一个系统,包含聊天、登录、支付朋友圈等子系统。
        ●朋友圈这个系统又包括动态、评论、点赞等子系统。
        ●评论这个系统可能又包括防刷子系统、审核子系统、发布子系统、存储子系统。
        ●评论审核子系统不再包含业务意义.上的子系统,而是包括各个模块或者组件,这些模块或者组件本身也是另外一个维度上的系统。例如,MySQL、Redis 等是存储系统,但不是业务子系统

 1.2 模块、组件、服务

模块:是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往使用模块作为合成的单位
组件:自包含的、可编程的、可重用的、与语言无关的软件单元,组件可以很容易被用于组装应用程序中模块和组件都是系统的组成部分,只是从不同的角度拆分系统而已。例如:
        ●从逻辑的角度来拆分系统后,得到的单元就是"模块”;从物理的角度来拆分系统后,得到的单元就是"组件”。
        ●划分模块的主要目的是职责分离;划分组件的主要目的是单元复用
例如我们要做一个学生信息管理系统

从逻辑的角度来拆分,可以分为:登录注册模块、个人信息模块、个人成绩模块;

从物理的角度来拆分,可以拆分为应用程序、Nginx. Web服务器、MySQL等
        ●服务:服务和组件有某种相似之处:它们都将被外部的应用程序使用。两者之间最大的差异在于:组件是在本地使用的(例如Jar文件) ;而服务是运行起来的,要通过同步或异步的远程接口来远程使用(例如RESTFul接口、web service.消息系统、RPC,或者socket)
服务是可以单独运行,并且对外提供功能的一种形式。可以将一个复杂的项目分解成多个服务。当某一个服务挂掉时不会拖垮整个系统。如果没有服务化,每当一个新的功能被添加到系统中就会影响到所有功能;如果采取服务化,每个服务只对其上下游的服务负责。

1.3 软件架构体系

 2. 架构原则

2.1 解耦

在软件工程中,耦合指的就是对象之间的依赖性。对象之间的耦合度越高,维护成本越高。因此对象的设计应使类和构件之间的耦合最小。软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。划分模块的一一个准则就是高内聚低耦合
耦合性存在于各个领域,而非软件设计中独有的,理论上说绝对的零耦合是做不到的,但可以通过一些方法将耦合降至最低,降低耦合度即可理解为解耦,在设计上解耦的核心思想是【彼此独立,互不依赖】。

2.2 分层

分层结构是最为流行、应用最广泛的应用软件的设计方式。在应用了分层结构的系统中,各个子系统按照层次的形式组织起来,上层使用下层的各种服务, 而下层对上层一无所知。每一层都对自己的上层隐藏其下层的细节。
经典三层架构: 
在软件架构中,经典三层架构自顶向下由用户界面层、业务逻辑层、数据访问层组成。在提出该分层架构的时代,多数系统往往较为简单,本质上都是- -个单体架构的数据库管理系统。这种分层架构有效地隔离了业务逻辑与数据访问逻辑,使得这两个不同关注点能够相对自由和独立地演化。经典的三层架构如下所示:

分层的设计原则:保证同一层的组件处于同一个抽象层次。即所谓的“单一抽象层次原则”,这一原则可以运用到分层架构中,比如下图所示:

 2.3 封装

假设我们有一个程序, 它在逻辑上有一些不同的对象,并且这些对象彼此之间会相互交流。
在一个类中,当每个对象的状态保持相对孤立,就实现了封装。其余的对象并不能观察到这个对象的状态。他们能做到的只有调用一些被称作"方法”的通用功能。
因此,对象使用方法掌控着自己的状态,除非明确允许,没有其他人可以接触到它。如果你想和某个对象交流,你需要使用提供的方法。但在默认情况下,你无法改变对象的状态。

3. 架构的方法

架构图是为了表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界,以及软件系统的物理部署和软件系统的演进方向的整体视图。要让干系人理解、遵循架构决策,就需要把架构信息传递出去,架构图就是一个很好的载体。不同的视角和角色,关注点也是不同的,看到的架构图是不一样的。

3.1 业务架构

使用者:CEO、CIO、CTO、产品总监

核心业务流程

 核心能力:

 3.2 功能架构图

使用者:产品总监、产品经理

示例:黑马头条功能架构图

 3.3 系统架构

使用者:系统架构师

 3.4 技术架构

使用者:系统架构师

示例一:https://www.processon.com/view/5f2a0bfb1e08533a629b7ed3

示例二:冷链项目技术架构图

 3.5 数据架构

使用者:CTO、系统架构师、数据架构师

示例一:数据模型

示例二:大数据平台架构

3.6 部署架构

 使用者:运维架构师

示例一:

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值