写点什么

Week_01 学习总结

用户头像
golangboy
关注
发布于: 2020 年 09 月 20 日

架构 = 架构元素 + 元素关系

资深软件系统开发者,需要输出 4+1 视图,对不同人员的关注点进行说明



  • logical view 针对终端用户,标明功能性需求。对系统进行功能分解与抽象,抽象来源于问题领域。

逻辑视图需要保持单一内聚的对象模型。逻辑视图属于静态视图。


  • process view 针对集成、性能、可扩展性方面的关注者,即系统集成人员。侧重于系统运行时的特性,关注的是非功能需求,如并发性,分布性,系统集成特性,容错能力。

过程视图是动态视图,表现的是逻辑视图中各个功能对象的分布,可以以多层的抽象进行描述,关注每个不同层级的不同方面。

  • development view 针对的开发人员,软件管理。侧重于软件系统的模块的组织与管理。系统模型图和子系统图等表达,是静态视图。

  • physical view 针对系统工程人员,系统的拓扑,通信,部署。

  • 场景将其他视图有机联系起来,可以用文本,也可以用图形表示。

不同的系统侧重点不同,对管理系统来说,侧重于功能与开发,因此关注点在逻辑视图与开发视图。对实时控制系统,侧重控制,过程视图和部署视图是其关注点

4+1 视图于我有何用?

软件系统是一个有多维度系统,这来源于其自身的复杂性。

对个人来说:

  • 零开始的架构设计

  1. 对系统进行分析,分析收集获取各种使用场景,使其图文化,方便后续进行回溯与参考。

  2. 在这个过程中有些场景可能是无效的,因此需要咨询相关方,确定各场景的有效性。

  3. 用例视图是重中之重。

  • 接手前人项目,在系统文档缺乏,一无所知的情况下

  1. 通过使用软件系统和咨询相关人员,描绘其功能性视图和用例场景视图,以作参考。

  2. 初步使用与了解后,需要获取其过程视图。这个时候需要对系统的非功能性设计有个总体的认知,一般而言,针对某些接口,由点破面,逐步描绘该视图。

  3. 过程视图在一些稍大的系统中,一张图不足以描述,需要多层次图进行描述,重点是对系统有个整体的认知。

  • 学习开源项目,关注点在于

  1. 能干什么,即系统有什么功能,功能逻辑视图。

  2. 模块如何组织,开发视图。

  3. 重点是过程视图,系统是如何运行的。

  4. 总结项目中使用到的技术,以及问题解决的思路。

  5. 开源项目除了查看源代码,使用工具调试运行时情况也是必要的。

如何画图,怎么产出?

架构过程是一个迭代的过程,需要反复确定需求

架构需求

产出用例图文,敲定功能需求点。

关注点有三

  • 系统质量目标

  • 系统业务目标

  • 系统开发人员业务目标

只有让参与评审的相关人员参与进需求架构的过程中,才能最终形成一致的意见。

需求评审的目标

  • 确定需求是否合理

  • 确定功能组件定义是否合理

问题分析

系统的架构是在对问题分析的基础上进行的,因此,首先需要对问题进行分析与定义,然后可归纳出有效的模型。

  1. 在问题定义上达成共识

问题概述:描述问题本质

影响:说明对哪些项目干系人产生的影响

结果:确定产生什么样的影响(商业活动和项目干系人)

优点:概要性提出解决方案,并列出该方案优点

  1. 理解问题本质

因果鱼骨图 + 头脑风暴 探究问题本质

  1. 确定干系人和用户

系统用户是谁?

系统客户是谁?

哪些人会受到系统输出影响?

谁会对它进行评估?

系统由谁来维护?

  1. 定义系统边界

面向对象的用例图(面向对象分析)

上下文范围图(结构化分析)

  1. 确定系统实现的约束

进度

投资

人员

预算

环境

操作系统

技术问题

行政问题

公司战略

程序工具语言的选择

分析方法

  • 面向数据流结构化分析方法(SA)

  • 数据流图(DFD):针对系统输入输出,处理过程与数据存储,有上到下多层次逐步细化数据处理过程。

  • 上下文范围关系图(context 图):描述系统的输入输出,与外部实体的关系,即系统的上下文范围

  • 面向数据结构 jackson 分析方法

  • 以数据结构为驱动,映射输出结构与输入结构的关系,这种关系由顺序、循环、条件组成通过图的形式表述。

  • 面向对象分析方法(OOA)

  • 用于建立动态模型的状态迁移图和 petri 网(基于工作流的问题分析)

如何进行系统设计

1、寻找系统目标间的平衡点,即妥协

2、总结学习参考他人的系统,甄别、取舍、补充来作为新系统的设计

架构设计

针对问题领域建模,产出领域模型,设计模型。避免涉及过多的内容和实现细节。

架构文档化

架构复审

过程总结

  1. 态度要端正,知道自己想要什么。

  2. 从 JD 中解读面试者传递的信息,做好准备,查漏补缺,从容应对。

  3. 架构是对现实世界客观事物的一种建模,模型的好坏决定架构的成败。

  4. 架构产出:4+1 视图。根据实际情况,产出架构文档,能针对管理者,开发人员,运维人员的不同关注点进行阐述,说明架构方案。这是一个沟通的过程。

  5. 团队中建立自己的技术领导力。


个人思考:

  1. 命题作业看似简单,但真正从实际的角度去考虑,从大局去思考,是有着不一样的难度。

  2. 对自己这种从未进行过架构思考的人来说,作业的过程,找不到关键点,自己的知识体系零散,不够全面,尤其涉及部署的时候,最能说明问题。

  3. 对后端缺少足够全面的认知,系统设计能力欠缺,体系框架凌乱。

用户头像

golangboy

关注

还未添加个人签名 2018.09.18 加入

还未添加个人简介

评论

发布
暂无评论
Week_01学习总结