什么是架构方法

软件架构,是有关软件结构与组件的抽象描述,用户指导大型软件系统各个方面的设计

对于架构的组成部分

  • 架构元素、元素间关系、架构、系统、架构文档、架构视图、相关方、关注点
  • 关系描述,一个系统应该有个架构,架构是架构元素和元素间关系组成的;元素就是服务器、组件、模块、子系统、类等元素;元素之间有两种关系,静态关系和动态关系,静态关系就是组合、聚合、关联、依赖、继承、泛化;动态关系,表示的它们是如何依赖交互的,以及如何相互调用整个系统运行的,比如一个用户登录不同的子系统是如何写协作的,元素、元素之间的静态关系、动态关系构成了整个架构,这些反映在架构文档中,一个架构文档是由多个架构视图组成的,架构视图反映的各个元素和元素之间的关系。不同的相关方的关注点是不一样的,做的架构做的是系统的架构,但是架构文档一定是给相关方看的,一定先明确架构文档是给谁看的

模型

模型元素,类、对象、结点、包、组件、元素关系

建模

用例建模,用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型用例的分析,使开发者能够有效地了解用户的需求。用例模型由若干个用例图构成,用例图中主要描述执行者和用例之间的关系。创建用例模型的工作包括,定义系统、确定执行者和用例、描述用例、定义用例间的关系、确认模型。

动态建模,主要描述系统的动态行为和控制结构。动态行为包括系统中对象生存期内可能的状态以及事件发生时状态的转移,对象之间动态合作关系,显示对象之间的交互过程以及交互顺序,同时描述了为满足用例需求所进行的活动以及活动间的约束关系。在动态模型中,对象间的交互是通过对象间消息的传递完成的。对象通过相互间的通信(消息传递)进行合作,并在其生命周期中根据通信的结果不断改变自身的状态。对象,通信,事件发生,状态改变

UML中的消息

简单消息,表示控制流,描述控制如何从一个对象传递到另一个对象,但不描述通信的细节

同步消息,是一种嵌套的控制流,用操作调用实现。操作的执行者要到消息相应操作执行完并回送一个简单消息后,再继续执行

异步消息,是一种异步的控制流,消息的发送者在消息发送后就继续执行,不等待消息的处理

分类

时序图,用来描述对象之间动态的交互行为,着重体现对象间消息传递的时间顺序。

两个轴,水平轴表示一组对象,垂直轴表示时间。时序图中的对象用于一个带有垂直虚线的矩形框表示,并标有对象名和类名。垂直虚线是对象的生命线,用于表示在某段时间内对象是存在的。对象间的通信通过在对象的生命线之间的消息来表示,消息的箭头类型指明消息的类型。

它的对象,是广义的对象,可以是类的对象,也可以是个人是个角色,也可以说是个模块,也可以是个子系统,可以是个服务器,可以是任务对象,不仅仅是狭义的对象,如果是类,表示的是类之间如何通过消息相互调用来协作的

虚线表示的是生命,表示生命是否终结,白色的长条表示的激活,是不是处于活动状态,通常处理消息时,它是处于活动状态;比如,给它发一个消息,它处于活动状态,消息处理完了返回了,活动状态就结束了

在对象层面,方法就是消息,当调用另一个类的方法时就是给它发消息

核心的元素,对象、生命线、激活、消息

什么时候使用,如何要开发的系统依赖一个支付系统,在需求分析阶段就应该画出来,画出的系统级的时序图,自己设计的系统和当前已经存在的系统之间的关系是什么样的;在概要设计阶段,有服务器、组件,可以画组件和服务器之间的时序图,服务器之间是如何交互,组件之间是如何交互,时序图可以在任务阶段使用,不同的阶段关注的元素是不同的,主要是关注这些模块之间动态交互的关系是什么样的。系统之间的消息存在异步的消息,类之间的消息不存在异步的消息。

消息在类的层面它是方法的名称,在服务器、组件、模块级别它可能真的就是描述的是一个什么样的消息

可以描述任何对象时序的关系,不光有关系,还有它们的调用时序

什么场景下子系统间的消息调用关系

 

活动图

描述了系统中各种活动的执行的顺序,刻画了所有进行的各项活动的执行流程,它既可以用来描述操作(类的方法)的行为,也可以描述用例和对象内部的工作过程,并可用于表示并行过程。活动是构成活动图的核心元素,是具有内部动作的状态,由隐含的事件触发活动的转移。活动的解释依赖于作图的目的和抽象层次,在概念层描述中,活动表示要完成的一些任务,在说明层和实现层,活动表示类中的方法

活动图是描述流程的,时序图是描述元素间的动态调用关系,活动图不表示动态间的动态间的动态调用关系,描述的是整个流程处理是如何完成的。在UML是没有流程图的,活动图是可以替代的。泳道,领域,一个流程可能是跨领域的,不同的泳道代表的是不同的领域,也可以是不同的服务器,不同的子系统。关注的是功能模块之间的流程

活动图是在什么阶段使用,可以在三个阶段的任意阶段使用,如果是业务流程是可以在需求分析阶段画的,在处理流程中经历了什么流程,在什么状态下合并分支,通过活动图画业务图的流程;概要设计阶段画活动图,画不同的模块不同的领域不同的子系统的处理流程是什么样的;详细设计阶段可以画到方法内部的处理流程,一个方法处理一个复杂逻辑的处理过程。

用活动图的感悟,我只需要安装puml的语法表达活动的逻辑,而刚好它画出的图是我想要的

状态图

描述一个特定对象的所有可能的状态及其引起状态的转移的事件。一个状态图包括一系列以及状态之间的转移。所有的对象都具有状态,状态是对象执行了一些列活动的结果。当某个事件发生后,对象的状态将发生变化。

状态图描述的是状态的变迁的,状态有哪些,状态之间的变化因何而产生。可以在需求分析和详细设计使用。

 

  • 视图分类
  • 开发视图
  • 相关者,开发相关人员,测试人员
  • 视角,系统如何开发实现
  • 主要元素,描述系统的层,分区,包,框架,系统通用服务,业务通用服务,类和接口,系统平台和相关基础框架
  • 用途,指导开发组织设计和开发实现
  • 物理视图
  • 相关者,系统集成商,系统运维人员
  • 视角,系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置
  • 主要元素,物理节点以及节点的通信
  • 过程视图
  • 相关者,性能优化,开发相关人员
  • 视角,系统运行时线程,进程的情况
  • 主要元素,系统进程,线程以及处理队列等
  • 常用的UML图分类
  • 用例图、类图、组件图、部署图、序列图、活动图、状态图
  • 用例图,主要在需求分析阶段使用
  • 需求分析
  • 系统大概要做什么,大体的功能、要求约束
  • 概要设计
  • 系统整体的高层架构,系统如何部署,系统有哪些模块,系统的流程是什么
  • 详细设计
  • 类图,类之间的关系
  • 三个阶段用不同的模型去表述,用例图主要在需求分析阶段,类图主要在详细设计阶段,类图不一定要把所有的类都画出来,主要看相关方,需要把核心的类画出来,核心类之间的继承和调用关系
  • 动态模型
  • 动态模型主要描述系统的动态行为和控制结构
  • 对象之间的消息都是同步消息,对象之间的消息就是方法的调用,类之间的调用一定是同步的
  • 组件图
  • 组件之间的依赖关系是指结构之间在编译,连接或执行时的依赖关系。
  • 用来描述物理组件模块的,模块间的关系是什么样的,模块的边界是什么样的。组件图是软件架构设计中最重要的图。到底在设计什么,就是要把功能里的模块给拆分清楚了,整个系统就是通过这些组件来完成。组件要设计多大,设计的关键点就在这里。有6种关系,更多的关系是依赖、组合、聚合等关系
  • 组件主要是在概要设计阶段,它是静态关系。组件之间的动态关系怎么画,通常用组件时序图来画
  • 组件图的粒度应该有多大,一个物理组件中可以包含多个逻辑组件,在一个物理组件中一个组件的大小可以是让开发者一个人负责一个组件的开发
  • 组件图不光描述的是组件间的依赖关系,它也描述开发的过程,开发者的指责分配,开发者之间的互相关系
  • 部署图
  • 部署图将的是物理方面的。主要是画服务器之间关系,一个立方体是一个服务器,有必要的话可以把服务器内的核心组件画出来。设计的系统最终部署到哪些服务器上,部署图有些服务器是自己要部署的服务器,有些服务器是现成的服务器,通过部署图也可以画出来,你新的系统和其他的服务器之间的依赖关系是什么样的,需要多少服务器。有哪些子系统,最后要部署到哪些服务器上。主要是概要设计阶段
  • 有个基本需求,进入设计阶段画的第一张图是,它是概要设计。可以画业务的流程图、活动图,业务的时序图,子系统的时序图,画用例图,这些通常是由产品经理来完成。架构师做的是概要设计和详细设计。架构设计,画的第一张图通常应该是部署图,头脑中应该有的应该是部署图,大概有什么样的服务器,承担什么职责,最后要做出来的系统长什么样。
  • 设计要考虑场景的,而不是设计的多么牛逼
  • 部署图是静态图,静态图总是要有动态图配合,来描述他们之间的依赖关系是什么样的,通常是时序图来完成的,时序图是要场景的
  • 系统 - 子系统 - 组件 - 类对象
  • 需求分析画的图,用例图、活动图、状态图、时序图
  • 概要设计画的图,部署图、组件图、(服务器、子系统、组件)时序图、活动图
  • 详细设计画的图,类图、状态图、(类)时序图、(类方法)活动图

脑图:https://share.mubu.com/doc/1fgxgqW2mn