论软件系统建模方法及其应用
2017
试题一论软件系统建模方法及其应用
软件系统建模(Software System Modeling)是软件开发中的重要环节，通过构建软件系统模型可以帮助系统开发人员理解系统、抽取业务过程和管理系统的复杂性，也可以方便各类人员之间的交流。软件系统建模是在系统需求分析和系统实现之间架起的一座桥梁，系统开发人员按照软件系统模型开发出符合设计目标的软件系统，并基于该模型进行软件的维护和改进。
请围绕”论软件系统建模方法及其应用”论题，依次从以下三个方面进行论述。1.概要叙述你参与的软件系统开发项目以及你所担任的主要工作。2.说明软件系统开发中常用的建模方法有哪几类?阐述每种方法的特点及其适用范围。3.详细说明你所参与的软件系统开发项目中，采用了哪些软件系统建模方法，具体实施效果如何。
摘要：
2022年3月，我负责了某公司基于云原生理念的“自动化运维系统”的建设项目，由我担任系统架构设计师，负责系统架构设计工作，在该项目的实施过程中，我们选择了面向对象建模方法，建模阶段主要包含面向对象分析建模和面向对象设计建模，在需求分析和架构设计阶段建立不同的架构模型，通过这些模型，极大的方便各类人员之间的交流，帮助开发人员理解系统，快速进行系统的实现。该项目总投入近450万，历时15个月，于2023年6月交付至今，不仅帮助运维人员高效、安全的管理云上应用和后端服务器资源，同时帮助开发和测试人员实现应用的快速迭代和测试，大大提升了团队之间的协作效率，消除了运维和开发之间的壁垒，得到了用户的一致好评。
正文：
随着云原生技术的发展，企业也逐渐引入相关技术，在基础设施层，越来越多的企业开始购买云上服务器，如应用服务器企业可选择阿里云的ECS服务器，数据库服务器企业可选择阿里云的RDS，DNS服务企业可选择阿里云的域名解析，云上资源购买十分方便，在页面中点击几下即可购买成功，但在实际工作中，不能随意购买，需要结合企业成本和服务器资源使用情况来综合考量，避免资源浪费，所以对云上资源的成本、资源使用情况的可视化管理就很重要。同时，随着容器技术和微服务架构的发展，企业应用也都选择微服务架构，采用容器的方式部署在kubernets集群中，在这种情况下，应用的快速发布、容器资源管理、监控告警就显得尤为重要。
为了实现云上资源的可视化管理和基于云原生应用的快速发布，我所在的公司决定开发一个“自动化运维”系统，我们称之为云平台，并在2022年3月正式启动该项目的建设工作，我被任命为系统架构设计师，负责系统架构设计工作。该项目总投入450万元人民币，建设周期从2022年3月至2023年6月截止，历时15个月。该系统主要包括应用中心、发布中心、监控中心、成本中心、容器中心、权限管理和变更管理七大模块，应用中心是整个系统的数据中心，其他模块的功能都围绕“应用”来进行资源的展示和操作；发布中心以“应用”为单位，向用户提供应用的快速发布功能；监控中心以“应用”为单位，向用户提供应用的监控告警功能；成本中心以“应用”为单位，向用户展示每个应用的成本；容器中心以“应用”为单位，展示应用的相关容器资源；权限管理是对用户分类，使得不同的用户可看到不同的模块；变更管理主要对云上资源的变更进行管控，避免对云上资源的误操作导致系统故障。
常见的软件系统建模方法有两种，结构化建模和面向对象建模：
结构化建模是一种自顶向下，逐步求精，使用模块化技术。把一个大问题分解为若干个小问题，或把一个抽象的问题分解为多个具体的问题，保证每个底层问题足够简单，容易理解。结构化建模方法适用于开发需求和流程稳定的系统。
面向对象建模是把现实生活中的物体抽象为对象，为每个对象创建一个类，通过关联、依赖、继承、实现和泛化表示类之间关系。面向对象的建模方法可修改性和可扩展性更强，在代码实现时，每个类创建一个文件，代码的可维护性和可修改行更强。通过类的封装、继承和多态，能灵活的进行功能的开发。
由于该系统结构较复杂，为了后期的可扩展性和新功能修改的灵活性，我们决定选择面向对象的方式进行系统的设计与开发。
在需求分析阶段，主要包含面向对象的用例建模和分析建模。
在用例建模时，主要设计用例图，步骤为识别用例参与者、合并需求获得用例、细化用例，调整用例模型，例如在应用中心模块，主要的用例参与者是开发、测试、运维，开发会进行应用生命周期的管理，包含应用的上线、下线、资源查看；测试会进行应用搜索和发布；运维会进行应用相关信息，包含实例ID、实例IP、负责人等信息，根据以上信息设计用例图。
在分析建模时，主要设计类图，步骤为设计类、识别类之间的关系、为类添加职责、建立交互图，还是以应用中心模块为例，主要类有应用类、环境类、集群类等，同时为每个类设计接口类，接口类中定义该类具有的操作，在实现类中书写具体的业务逻辑
在数据建模时，主要设计实体关系图（E-R图），在应用中心中，实体主要有应用、环境、集群，三者的关系为一个应用有多个环境，一个环境有多个应用，应用和环境是多对多的关系；一个应用可在多个集群部署，一个集群可部署多个应用，应用和集群是多对多的关系；一个环境有多个集群，一个集群只属于一个环境，环境和集群是一对多的关系。
在设计阶段，根据需求分析阶段的模型进行分析设计，首先设计整个系统的架构图，在整个系统架构设计时，为了提升系统的可扩展性、可修改性、可维护性，我们采用了微服务架构，整体架构设计完成之后，还要对每个微服务进行架构设计，在架构设计过程中中，采用流程图来描述架构，采用活动图来表示并发，采用时序图来详细描述每个对象之间的交互，包含同步消息、异步消息和返回消息，对程序的流程进行详细设计，帮助开发了解逻辑细节，并进行代码的研发。
整个系统采用分层架构，主要包含表示层、业务逻辑层、数据层，表示层采用vue语言进行前端页面的开发，业务逻辑层使用golang语言进行每个微服务的逻辑实现，每个微服务通过grpc协议进行通信，在数据层使用关系型数据mysql 进行数据的持久存储、使用redis提供缓存功能，使用elasticsearch来提供快速检索功能。
经过近15个月的项目开发，“自动化运维系统”顺利投入使用，开发人员和测试人员可通过该系统实现应用发布的自动化，无需运维人员的协助，消除了运维和开发的固有壁垒；运维人员可通过该系统高效管理云上资源，实时查看云上资源的使用率和成本，减少资源浪费，提高资源使用率。当然，在本项目中还有一些不足之处，在进行云上资源成本统计时，最初我们通过阿里云的费用接口来拉取各个产品的成本，由于产品很多，写了很多逻辑，后来通过和阿里云的技术人员沟通，可以在阿里云平台上将所有产品的费用一键转储到oss中，直接通过oss的sdk即可快速查询所有产品的费用，后来我们开发人员快速修改下成本获取的逻辑，并没有对项目产生什么影响。由于架构合理且考虑周全，进展顺利，得到了公司技术人员的认可，大大提高了技术团队的协作效率。