网站策划编辑的职责,门户网站意思,查询建设用地规划许可证在哪个网站,随机显示wordpressJava全能学习面试指南#xff1a;https://javaxiaobear 首先#xff0c;请你设想这样一个场景#xff1a;如果公司安排你做架构师#xff0c;要你在项目开发前期进行软件架构设计#xff0c;你该如何开展你的工作#xff1f;如何输出你的工作成果#xff1f;如何确定你的… Java全能学习面试指南https://javaxiaobear 首先请你设想这样一个场景如果公司安排你做架构师要你在项目开发前期进行软件架构设计你该如何开展你的工作如何输出你的工作成果如何确定你的设计是否满足用户需求你是否有把握最后交付的软件是满足要求的是否有把握让团队每个工程师清楚自己的职责范围并有效地完成开发工作……
这些问题其实都是软件开发管理与技术架构的核心诉求而架构师的核心工作就是做好软件设计解决这些诉求。这些问题搞定了软件的开发过程和结果也就都得到了保证。那怎么实现这些诉求呢我们主要的手段就是软件建模以及将这些软件模型组织成一篇有价值的软件设计文档。
1、软件建模 所谓软件建模就是为要开发的软件建造模型。 模型是对客观存在的抽象例如著名的物理学公式 E M c 2 E Mc^2 EMc2 就是质量能量转换的物理规律的数学模型。除了物理学公式以外还有一些东西也是模型比如地图是对地理空间的建模机械装置、电子电路、建筑设计的各种图纸是对物理实体的建模。而软件也可以通过各种图进行建模。
软件系统庞大复杂通过软件建模我们可以抽象软件系统的主要特征和组成部分梳理这些关键组成部分的关系。在软件开发过程中依照模型的约束开发系统整体的格局和关系就会可控。相关人员从始至终都能清晰了解软件的蓝图和当前的进展不同的开发工程师会清晰自己开发的模块和其他同事工作内容的关系与依赖并按照这些模型开发代码。
那么我们是根据什么进行软件建模的呢要解答这个疑问你需要先知道在软件开发中有两个客观存在。
一个是我们要解决的领域问题。比如我们要开发一个电子商务网站那么客观的领域问题就是如何做生意卖家如何管理商品、管理订单、服务用户买家如何挑选商品如何下订单如何支付等等。对这些客观领域问题的抽象就是各种功能及其关系、各种模型对象及其关系、各种业务处理流程。
另一个客观存在就是最终开发出来的软件系统。软件系统要解决的问题包括软件由哪些主要类组成这些类如何组织构成一个个的组件这些类和组件之间的依赖关系如何运行期如何调用需要部署多少台服务器服务器之间如何通信等。
而对这两个客观存在进行抽象化处理的手段就是我们的软件模型。 一方面我们要对领域问题和要设计的软件系统进行分析、设计、抽象另一方面我们根据抽象出来的模型进行开发最终实现出一个软件系统这就是软件开发的主要过程。而对领域问题和软件系统进行分析、设计和抽象的这个过程就是软件建模设计。
2、软件设计方法
因此软件设计其实就是软件建模的过程。我们通过软件建模工具将软件模型画出来实现软件设计相信大部分在软件工程这课程都学到过那时候也不了解学这个有啥含义用到什么地方。
在实践中通常用来进行软件建模画图的工具是 UML统一建模语言。UML 包含的软件模型有 10 种其中常用的有 7 种类图、序列图、组件图、部署图、用例图、状态图和活动图。
下面我们简单了解下这 7 种常用 UML 图的使用场景和基本样例。当然如果你想更详细地学习 UML 知识我也非常鼓励并且推荐你阅读马丁富勒的《UML 精粹》一书。
1、类图
类图是最常见的 UML 图形用来描述类的特性和类之间的静态关系。
一个类包含三个部分类的名字、类的属性列表和类的方法列表。类之间有 6 种静态关系关联、依赖、组合、聚合、继承、泛化。把相关的一组类及其关系用一张图画出来就是类图。
比如你在后面的课程中会遇到下面这幅图它就是类图。你可以把我上面说的类图包含元素和图片一一对照感受类图的用法。 2、时序图
类图之外另一种常用的图是时序图类图描述类之间的静态关系时序图则用来描述参与者之间的动态调用关系。 从图中可以看出每个参与者有一条垂直向下的生命线这条线用虚线表示。而参与者之间的消息从上到下表示其调用的前后顺序关系这正是“时序图”这个词的由来。每个生命线都有若干个激活条也就是那些细长的矩形条只要这个条出现就表示参与者是激活状态的。
时序图通常用于表示参与者之间的交互这个参与者可以是类对象也可以是更大粒度的参与者比如组件、服务器、子系统等。总之只要是描述不同参与者之间交互的都可以使用时序图。
3、组件图
组件是比类粒度更大的设计元素一个组件中通常包含很多个类。组件图有的时候和包图的用途比较接近组件图通常用来描述物理上的组件比如一个 JAR、一个 DLL 等等。在实践中我们进行模块设计的时候用得更多的就是组件图。 组件图描述组件之间的静态关系主要是依赖关系如果你想要描述组件之间的动态调用关系可以使用组件时序图以组件作为参与者描述组件之间的消息调用关系。
4、部署图
部署图描述软件系统的最终部署情况比如需要部署多少服务器关键组件都部署在哪些服务器上。 部署图是软件系统最终物理呈现的蓝图根据部署图所有相关者诸如客户、老板、工程师都能清晰地了解到最终运行的系统在物理上是什么样子和现有的系统服务器的关系和第三方服务器的关系。根据部署图还可以估算服务器和第三方软件的采购成本。
因此部署图是整个软件设计模型中比较宏观的一种图是在设计早期就需要画的一种模型图。根据部署图各方可以讨论对这个方案是否认可。只有对部署图达成共识才能继续后面的细节设计。
5、用例图
用例图通过反映用户和软件系统的交互描述系统的功能需求。 图中小人形象的元素被称为角色角色可以是人也可以是其他的系统。系统的功能可能会很复杂所以一张用例图可能只包含其中一小部分功能这些功能被一个矩形框框起来这个矩形框被称为用例的边界。框里的椭圆表示一个一个的功能功能之间可以调用依赖也可以进行功能扩展。
6、状态图
状态图用来展示单个对象生命周期的状态变迁。
业务系统中很多重要的领域对象都有比较复杂的状态变迁比如账号有创建状态、激活状态、冻结状态、欠费状态等等各种状态。此外用户、订单、商品、红包这些常见的领域模型都有多种状态。
这些状态的变迁描述可以在用例图中用文字描述随着角色的各种操作而改变但是用这种方式描述状态散乱在各处不要说开发的时候容易搞错就是产品经理自己在设计的时候也容易搞错对象的状态变迁。
UML 的状态图可以很好地解决这一问题一张状态图描述一个对象生命周期的各种状态及其变迁的关系。如图所示门的状态有开 Opened、关 Closed 和锁 Locked 三种状态与变迁关系用一张状态图就可以搞定。 7、活动图
活动图主要用来描述过程逻辑和业务流程。UML 中没有流程图很多时候人们用活动图代替流程图。 活动图和早期流程图的图形元素也很接近实心圆代表流程开始空心圆代表流程结束圆角矩形表示活动菱形表示分支判断。
此外活动图引入了一个重要的概念——泳道。活动图可以根据活动的范围将活动根据领域、系统和角色等划分到不同的泳道中使流程边界更加清晰。
8、绘图推荐
UML绘图软件有推荐ProcessOn和draw.io大家习惯用哪个就哪个
我们上面介绍了 UML 建模常用的 7 种模型那么这 7 种模型分别应用在软件设计的什么阶段用来表达什么样的设计意图呢
3、软件设计文档
软件设计文档就是架构师的主要工作成果它需要阐释这节课开头提到的各种诉求描绘软件的完整蓝图而软件设计文档的主要组成部分就是软件模型。
软件设计过程可以拆分成需求分析、概要设计和详细设计三个阶段。
在需求分析阶段主要是通过用例图来描述系统的功能与使用场景对于关键的业务流程可以通过活动图描述如果在需求阶段就提出要和现有的某些子系统整合那么可以通过时序图描述新系统和原来的子系统的调用关系可以通过简化的类图进行领域模型抽象并描述核心领域对象之间的关系如果某些对象内部会有复杂的状态变化比如用户、订单这些可以用状态图进行描述。
在概要设计阶段通过部署图描述系统最终的物理蓝图通过组件图以及组件时序图设计软件主要模块及其关系还可以通过组件活动图描述组件间的流程逻辑。
在详细设计阶段主要输出的就是类图和类的时序图指导最终的代码开发如果某个类方法内部有比较复杂的逻辑那么可以将这个方法的逻辑用活动图进行描述。
我们在每个设计阶段使用几种 UML 模型对领域或者系统进行建模然后将这些模型配上必要的文字说明写入到文档中就可以构成一篇软件设计文档了。
设计文档的写法并没有一定之规最重要的是这个文档能否向阅读者传递出架构师完整的设计意图。而不同的阅读者关注点是不同的老板、客户、运维、测试、开发这些角色都是设计文档的阅读者他们想要看到的东西显然是不一样的。
客户和测试人员可能更关注功能性需求和实现逻辑老板和运维人员可能更关注非功能需求和整体架构而开发人员可能更关注整体架构与关键技术细节。
架构、系统文档、相关人员之间的关系可以参考下面这张图。 上面这张图是关于架构的架构图也就是说是关于软件模型的模型
每个软件系统都需要有一个架构每个架构都包含若干架构元素。架构元素就是前面提到的服务器、组件、类、消息、用例、状态等等。这些元素之间的关系是什么如何把它们组织在一起我们可以用部署图、组件图、时序图等各种模型图来描述。
架构最终需要一个文档来承载把这些模型图放进这个文档再配以适当的文字说明就是一篇架构设计文档。而设计文档是给人阅读的这些人就是系统的相关方。不同的相关方关注点不同也需要由不同的模型图来进行表达所以架构师应该针对不同的相关方
使用不同的模型图输出不同的架构文档。
架构图是为了表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界以及软件系统的物理部署和软件系统的演进方向的整体视图。要让干系人理解、遵循架构决策就需要把架构信息传递出去架构图就是一个很好的载体。不同的视角和角色关注点也是不同的看到的架构图是不一样的。
具体可参考我这篇架构视角
4、总结
软件设计就是在软件开发之前对要解决的业务问题和对要实现的软件系统进行思考并将这个思考的结果通过软件模型表达出来的过程。
软件系统的开发是一个复杂的智力活动参与其中的我们更需要拥有构建蓝图并付诸实践的能力。
目前有个很火的词叫“元宇宙”“元”通俗地讲就是一切开始的地方是关于如何用自己描述自己是抽象之上的抽象。这种“元”能力对架构师而言非常重要。架构师只有掌握各种技术背后的技术了解各种问题背后的问题才能超越当下的种种羁绊设计出面向未来的架构。
