ARTICLE · 1165384
论基于架构的软件设计方法及应用(范文)

架构设计就是画几张框架图?
论基于架构的软件设计方法及应用
ABSD · 4+1 视图 · 数据中心管理系统
基于架构的软件设计方法
📦 6 Parts + Conclusion
👉 滑动
PART 01
背景与项目
数据中心统一管理
PART 02
六阶段方法论
ABSD 全流程
PART 03
结合项目实战
需求 · 设计 · 实现
PART ///
写在最后
经验与反思
摘要
2017 年 5 月,我参加了公司“数据中心管理系统”项目的开发,并担任系统架构师职务,负责系统的架构设计。该系统旨在将公司分散在全国各地的数据中心内的设备实现终端统一监控并管理。本文以数据中心管理系统为例,论述了基于架构的软件设计方法在项目中的具体应用,着重从架构需求、架构设计、架构实现三个阶段展开介绍。在架构需求阶段,通过用户访谈、问卷调查、现场观摩、构造原型的方式全面获取了需求;在架构设计阶段,通过 UML 模型中的 4+1 视图对系统的架构进行建模;在架构实现阶段,对系统构件进行了获取、开发和组装。该项目于 2018 年 11 月完成验收后正式上线,交付至今运行稳定,得到了公司的嘉奖和用户的一致好评。
ABSD · 基于架构的软件设计
由商业、质量和功能需求的组合驱动架构设计
01
PART
背景与项目概述
BACKGROUND · 项目从哪来
2016 年 7 月,中国电信提出适应智能化时代、通过智能牵引转型升级的 3.0 战略,着重推进网络智能化、业务生态化、运营智慧化,构建行业领先的物联网开放平台,为客户提供强大的物联网能力应用服务,重塑客户业务流程,挖掘业务价值,降低运营成本。
公司一方面落实集团战略,另一方面也因为业务多年来的不断扩展,在全国各地逐渐建设了多个数据中心。传统的数据中心管理模式是单机的,即为每一个数据中心设计一套管理系统,安排管理人员负责状态监控、事件处理和数据上报等工作。随着数据中心的不断增多、地域分布广泛,继续沿用传统的单机模式必将增加大量的人力物力开支。
如何统一管理所有设备、降低管理成本,成了公司亟待解决的问题
公司多年从事数据中心的设备生产、模块设计、设备管理以及相关软件开发,有着丰富的相关经验。经各部门领导商讨后决定,由开发部门负责开发一套数据中心管理系统。公司组建了12 人的开发团队和 3 名系统实施人员,并任命我为该项目的系统架构师,负责软件架构设计和开发工作。
系统经过仔细梳理之后,拆分为四个主要模块。
02
PART
ABSD 六阶段方法论
METHODOLOGY · 方法论拆解
ABSD 是架构驱动的,强调由商业、质量和功能需求的组合驱动软件架构设计,强调用视角与视图描述软件架构、用用例与质量场景描述需求。ABSD 有三个基础,即功能分解、架构风格的选择,以及软件模板的使用。本文首先介绍 ABSD 的开发阶段及每个阶段包括的活动,再结合项目论述它的具体应用,最后讨论我在开发过程中遇到的问题、解决方案与个人感悟。
ABSD 的三个基础
功能分解 · 架构风格选择 · 软件模板使用
基于架构的软件设计方法(ABSD)包括架构需求、架构设计、架构文档化、架构复审、架构实现和架构演化六个阶段。
✦ 接下来结合项目
下面从架构需求、架构设计、架构实现三个阶段,展开 ABSD 在项目中的具体应用。
03
PART
架构需求:全面获取需求
REQUIREMENTS · 需求获取
架构需求阶段,要明确用户对系统在功能、行为、性能、设计约束等方面的期望。在本项目中,主要问题是有效、快速地全面获取需求。
需求前期 · 访谈与问卷
INTERVIEW & QUESTIONNAIRE
我们采用用户访谈和调查问卷相结合的方式,把需求调研团队分成几组,分别进行需求收集。通过与课程教学组长的详细沟通,对系统的主要业务功能、用户角色等有了整体、全面的了解;之后又制作调查问卷表格下发给各位任课教师,统计整理后获悉了编程课程的教学活动与过程细节。
需求中期 · 现场观摩
ON-SITE OBSERVATION
在课程教学组长的协助和安排下,我们跟随任课教师前往学校的计算机实验室,对编程课程的实验教学现场进行观摩,了解了传统实验教学方式中学生与教师的具体操作流程。
需求后期 · 快速原型
RAPID PROTOTYPING
在基本完成大部分业务需求收集后,我们通过快速原型法构造出一个仿真的 OJ 系统,供用户试用与反馈,让用户也参与到设计中,提供了工作流程方面、业务领域方面不可或缺的经验,也为以后项目通过验收提供了有力支持。
04
PART
架构设计:4+1 视图建模
DESIGN · 架构建模
架构设计阶段,主要问题是如何合理地设计与描述软件架构。我们以 UML 模型中的 4+1 视图 来对架构进行建模。
场景视图 · 用例图
结合用户需求,在系统中划定了在校学生、任课教师、系统管理员、校外人员四类用户角色,并分别为这些角色标识了相应用例。
逻辑视图 · 包图
经过分析,我们决定采用微服务架构风格开发,将系统分为前端 Web 服务、平台保障服务、业务服务三部分。
前端 Web 服务
由负载均衡与服务器集群结合
平台保障服务
分为 API 网关、服务注册中心、监控平台,用以实现基础服务框架
业务服务
分为多个微服务,实现具体业务功能
物理视图 · 部署图
系统微服务采用分布式的部署方法,每个微服务根据实际情况,可在同一台物理机器或多台物理机器上同时部署多个实例。集群通过负载均衡做统一访问,部署为路由模式,系统内部网络与外部网络分属于不同的逻辑网络。在负载均衡算法的选择上,使用了最小连接法。
05
PART
架构实现:构件与组装
IMPLEMENTATION · 构件实现
架构实现阶段,主要问题是系统构件如何实现和组装。构件实现分为两种方式:获取现有构件、开发新构件。
构件获取:集成与自研并行
系统需要与教务管理和 OA 系统对接,我们使用开发商提供的 SDK 实现;微服务架构的基础框架,如 Spring Cloud、Eureka,以及评测机调用的编译器等,直接集成第三方软件实现。对于常见信息系统共同具备的用户管理、角色权限管理、日志记录、内容维护、消息中心等基本功能,通过取用单位过往项目中积累的相应构件来实现。
对于系统专属功能构件,则需要专门开发。我们使用了多种设计模式:通过装饰器模式实现同一试题在实验作业、比赛、考试等多种使用场景下的扩展功能;通过策略模式实现评测机对 C 语言、Java、Python 等多种编程语言的不同编译方法。
构件组装:按业务类型选择
构件实现完成后,我们根据不同业务类型,采用了不同的构件组装方式。
考试服务
从题库获取试题信息,采用同步消息方式
程序评测服务
属于耗时操作,采用异步消息方式
审批流程类业务
采用基于工作流的组装方式
///
LAST
写在最后
SUMMARY · 经验与反思
从本次项目开发整体来看,良好的架构风格选择使模块间耦合度降低,提高了系统的性能、可用性和可修改性等多项指标,满足了公司的预期要求,保证了系统后期的快速二次开发和数据接入。但在开发过程中,也遇到了一些问题。
!问题 01 🕳
设备数量较多,仅使用 ID 标识设备会导致数据可视化效果较差,难以定位设备。
✦ 解决方案
采用经纬度定位与设备 ID 标识相结合的方法,使用 ECharts + VUE 获取数据,以百度地图为基底直观展示所有设备,方便快速定位。
!问题 02 🕳
大量的控制层代码与关系数据库持久层交互,使运行速率较低。
✦ 解决方案
增加 Redis 作为缓存、Elasticsearch 作为搜索引擎。虽然增加了系统的复杂性,但数据访问速率得到了极大的提高。
此次项目的顺利完成为我在架构风格选择等方面积累了更多经验,同时也暴露出自身在这方面的不足。我应当总结本次项目经验,力争在下个项目中做得更好。
我是 violetdream,热衷于分享软件架构设计师论文范文
既然看到这里了,如果觉得有用,随手点个赞、在看、转发三连吧。
THANKS FOR READING