很多做软件开发同学的梦想都是成为一名架构师, 而架构师的核心工作就是做好软件设计. 软件设计是软件开发过程中的一个重要环节, 那么如何进行软件设计, 其输出标准又是什么呢? 软件设计过程中, 如何和各个相关方沟通, 使软件设计能同时满足用户的功能需求和非功能需求, 并降低公司的开发成本?
前期思考
很多软件开发同学的职业规划都是架构师, 试想这样一个场景, 如果公司安排你做架构师, 让你在项目开发前期进行了一些架构设计.
你该如何开展你的工作?
应该如何说出你的工作成果?
你如何确定你的设计是否满足用户需求的?
你是否有把握最后交付的软件是满足要求的?
是否有把握让软件团队每个工程师清晰了解自己的职责范围, 并有效的完成开发工作?
架构师的核心工作就是做好软件架构设计, 软件设计是软件开发过程中一个重要的环节.
如何进行软件设计?
软件设计的输出是什么?
软件升级过程中如何和各个相关方沟通?
软件设计如何既能满足用户的功能需求, 又能满足用户的非功能需求, 也能满足用户的成本要求?
如何能够使开发工程师, 测试工程师, 运维工程师, 理解软件的整体架构, 主要模块划分, 关键技术实现, 核心领域模型, 使他们能够做好自己的工作, 从而使整个软件开发过程, 处于一个可控的范围之内, 并在软件开发之初, 就对软件未来的蓝图有个清晰的认识?
以上这些诉求可以说是软件开发管理与技术的核心诉求, 这些问题搞定了, 软件的开发过程和结果也就得到了保障.
核心关键点
两个客观存在
我们再来看看, 解决这些问题你需要理解的核心关键点, 也就是说究竟如何做软件设计, 解决方法就是软件建模, 就是软件的抽象模型, 这些模型之上配上文字说明, 就形成了软件的设计文档.
模型是对客观存在的抽象, 在软件开发中有两个客观存在:
一个是我们要解决的领域问题, 比如我们要开发一个电子商务网站, 那么客观的领域问题就是如何做生意, 卖家如何管理商品, 管理订单服务用户, 买家如何挑选商品, 如何下单, 如何支付等等, 对于这些客观领域问题的抽象就是各种功能及其关系, 各种模型对象及其关系, 各种业务处理流程.
另一个客观存在就是最终开发出来的软件系统, 这个软件系统也是客观存在的.
软件有哪些主要组成?
这些类如何组织成一个一个的组件?
这些内核组件之间的依赖关系是如何的?
运行期如何调用, 需要部署多少台服务器?
服务器之间如何通信?
所以这两方面的客观存在的抽象就是我们的软件模型.
一方面, 我们要对领域问题和软件系统进行分析, 设计抽象, 另一方面, 我们根据抽象出来的模型, 进行软件开发, 这就是软件开发的主要过程.
而对领域问题和软件系统进行分析, 设计抽象, 这个过程我们称它为软件建模与设计.
UML 工具
软件建模工具很多, 目前主要是统一建模语言 UML.
所谓的建模, 就是对领域问题和软件系统进行抽象设计, 一个工具完成前述软件开发过程中的两个客观存在的建模.
而所谓的语言, 一则用于沟通, 满足设计阶段和各个相关方沟通的目的, 一则用于思考, 即使软件开发过程中不需要跟其他人沟通, 或者还没有到了沟通的时候, 依然可以使用 UML 建模, 帮助自己进行设计思考.
此外, 语言还有个特点, 就是有方言, 就我观察不同公司, 不同团队, 都有自己的特点, 并不需要拘泥于以往那样规范和语法, 只要不引起歧义, 在使用过程中对语法元素适当变通, 这是 UML 的最佳时间.
软件建模与设计过程又可以拆分成需求分析, 概要设计, 详细设计三个阶段, 而软件建模的主要工具是 UML, 下面我们看一下使用方法包含了哪些软件模型, 常用的有 7 种.
7 种软件模型
下面我们讨论这 7 种模型图, 如何在三个阶段使用.
类图
类图是最常见的 UML 图形, 用来描述类的特性和类之间的静态关系, 一个类包含三个部分, 类的名称, 类的属性列表, 类的方法列表之间有 6 种静态关系关联, 关联, 依赖, 聚合, 组合, 继承, 泛化, 而相关的一组类及其关系, 用一张图画出来就是类图, 类图主要是在详细设计阶段化, 如果内图已经设计出来了, 那么开发工程师只需要按照内图实现代码就可以了, 只要类的方法逻辑不是太复杂, 不同的工程是实现出来的代码几乎是一样的, 从而保证软件的规范统一.
实践中通常不需要把一个软件所有的类都画出来, 把核心的有代表性的, 有一定技术难度的内画出来, 一般就可以了, 除了在详细设计阶段画类图, 在需求分析阶段, 也可以将关键的领域模型对象图, 用例图画出来, 这个阶段, 关注的是领域对象的识别及其关系, 所以通常用简化的类图来描述.
序列图
序列图描述类之间的关系, 描述参与者自己的动态调用关系, 每个参与者有一条垂直向下的生命线, 用虚线表示, 而参与者之间的消息, 也从上到下表示其调用的前后顺序关系.
每个生命线都有个结果, 只有在参与者活动的时候才是激活的, 序列图通常用于描述对象之间的交互, 这个对象可以是类对象, 也可以是更大粒度的参与者, 比如组件, 比如服务器, 比如子系统. 总之, 只要描述不同参与者之间的交互的, 都可以使用序列图, 也就是说, 在软件设计的各个阶段, 都可以画序列图.
组件图
组件是更大粒度的设计元素, 一个组件中通常包含多个类, 组件图有时候和包的用途比较接近, 组件可以描述逻辑上的组件, 也可以描述物理上的组件, 比如一个 JAR, 一个 DLL 的, 因此组件图更灵活一点, 实践中, 用组件图而不是包图进行模块设计更常见一些.
组件图描述中间之间的静态关系, 主要是依赖关系, 如果想要描述组件之间的动态调用关系, 可以使用组件序列图, 以组建作为参与者, 描述组件之间的消息调用关系, 因为组件的力度比较粗, 通常用于描述设计软件的模块及其之间的关系, 需要在设计早期阶段就画出来.
部署图
他是描述软件系统的最终部署情况, 需要部署多少台服务器? 关键组件都部署在哪些服务器上? 部署图呈现的是系统最终物理呈现的蓝图.
根据部署图, 所有相关者, 客户, 老板, 工程师, 都能够清晰的了解到最终运行的系统, 物理上是什么样子? 和现有系统服务器的关系, 和第三方服务器的关系.
根据部署图, 还可以估算出服务器和第三方软件的采购成本.
因此, 部署图是整个软件设计模型中比较宏观的一张图, 在设计早期就需要画的一张模型图. 根据部署, 各方可以讨论是否对这个方案认可, 只有对部署图达成共识, 才能够继续后面的细节设计, 部署图主要用在概要设计阶段.
用例图
主要在需求分析阶段, 通过反映用户和软件系统之间的交互, 描述软件的功能需求, 图中小人物被称为角色, 角色可以是人, 也可以是其他的系统, 系统的功能可能会很复杂, 所以一个用例图, 可能只包含其中一小部分功能, 这些功能被一个巨型框框起来, 这个巨型框被称为用力的边界, 框里的椭圆, 表示一个一个的功能, 功能之间可以调用依赖, 也可以进行功能扩展, 因为用例图中功能描述比较简单, 通常还需要对用例图配以文字说明, 形成需求文档.
状态图
用来展示单个对象生命周期的状态变更, 业务系统中, 很多重要的领域对象对于比较复杂的状态变迁, 比如账号, 有创业状态, 激活状态, 冻结状态, 欠费状态等等各种状态, 因此, 用户订单商品红包这些常见的领域模型, 都有多种状态, 这些状态的变迁描述, 可以在用例图中用文字描述, 随着角色的各种操作而改变, 但是这种描述方式, 状态散落在各处, 做开发的时候容易搞错, 就是产品经理自己在设计的时候, 也容易搞错对象的状态变迁, 状态图可以很好的解决这一问题.
一张状态图描述一个对象生命周期的各种状态及其变迁的关系.
活动图
主要用来描述过程逻辑, 业务流程. UML 中没有流程图, 很多时候人们用活动图代替流程图, 活动图和早期流程图的图形元素也很接近.
实心圆代表流程开始, 空心圆代表流程结束, 圆角矩形表示活动, 菱形表示分支判断, 此外, 引入了一个重要的概念, 泳道. 可以根据活动的范围, 将活动根据领域, 系统角色的, 划分到不同的泳道中, 使流程边界更加清晰明了.
总结
模型图本身并不复杂, 几分钟的时间就可以学习一个模型图的画法. 难的是如何在合适的场合下用正确的 UML 模型, 表达自己的设计意图, 从而形成一套完整的软件模型, 进而组织起一个言之有物, 层次分明, 可以指导开发, 在团队内部达成共识的设计文档.
我们从软件设计的不同阶段这一维度重新梳理一下, 如何使用正确的模型进行软件建模.
需求分析
在需求分析阶段, 主要是通过用例图描述系统的功能与使用场景; 对于关键的业务流程, 可以通过活动图描述. 如果在需求阶段, 就提出要和现有的某些子系统整合, 可以通过时序图, 描述新系统和原来的子系统的调用关系.
核心领域对象, 可以通过简化的类图进行模型领域抽象, 并描述核心领域对象之间的关系.
如果某些对象内部有复杂的状态变化, 比如用户, 订单这些, 可以用状态图进行描述.
概要设计
在概要设计阶段, 通过部署图, 描述系统最终的物理蓝图, 通过组件图以及组件时序图, 设计软件主要模块及其关系, 还可以通过组建活动图, 描述组件之间的流程逻辑.
详细设计
在详细设计阶段, 主要输出的就是类图和类的时序图, 直到最终的代码开发, 如果某个类方法内部, 有比较复杂的逻辑, 那么可以画方法的活动图进行描述, UML 的工具可以是很复杂的, 收费的, 比如 EA 这样的大型软件工具. 也可以使用 processon 在线的免费的工具. 对于一般的开发者, 建议从简单的用起, 因为那个建模可以很复杂, 也可以很简单, 简单掌握类图, 时序图, 组件图, 部署图, 用例图, 状态图, 活动图. 在 7 种模型图, 灵活的在需求分析, 概要设计详细设计阶段, 根据场景的不同, 绘制对应的模型图, 可以实实在在的做好软件建模, 搞好系统设计, 作为一个掌控局面, 引领技术团队的架构师.
来源: https://www.cnblogs.com/jackyfei/p/12093951.html