- 推荐序一:架构师真正要学会的事情
- 推荐序二
- 译者序 2.0
- 序
- 关于本书
- Part Ⅰ 什么是软件架构
- 第 1 章 什么是架构
- 第 2 章 架构的种类
- 第 3 章 软件架构是什么
- 第 4 章 敏捷软件架构是什么
- 第 5 章 架构对上设计
- 第 6 章 软件架构重要吗
- 第 7 章 问题
- Part Ⅱ 软件架构的角色
- 第 8 章 软件架构的角色
- 第 9 章 软件架构师应该编码吗
- 第 10 章 软件架构师应该是建造大师
- 第 11 章 从开发者到架构师
- 第 12 章 拓展 T
- 第 13 章 软技能
- 第 14 章 软件架构不是接力运动
- 第 15 章 软件架构要引入控制吗
- 第 16 章 小心鸿沟
- 第 17 章 未来的软件架构师在哪里
- 第 18 章 每个人都是架构师,除非他们有其他身份
- 第 19 章 软件架构咨询师
- 第 20 章 问题
- Part Ⅲ 设计软件
- 第 21 章 架构驱动力
- 第 22 章 质量属性(非功能需求)
- 第 23 章 处理非功能需求
- 第 24 章 约束
- 第 25 章 原则
- 第 26 章 技术不是实现细节
- 第 27 章 更多分层等于更高复杂度
- 第 28 章 协同设计是一把双刃剑
- 第 29 章 软件架构是对话的平台
- 第 30 章 SharePoint 项目也需要软件架构
- 第 31 章 问题
- Part Ⅳ 可视化软件
- 第 32 章 沟通障碍
- 第 33 章 对草图的需要
- 第 34 章 无效的草图
- 第 35 章 C4:语境、容器、组件和类
- 第 36 章 语境图
- 第 37 章 容器图
- 第 38 章 组件图
- 第 39 章 是否包含技术选择
- 第 40 章 你会那样编码吗
- 第 41 章 软件架构和编码
- 第 42 章 你不需要 UML 工具
- 第 43 章 有效的草图
- 第 44 章 C4 的常见问题
- 第 45 章 问题
- Part Ⅴ 为软件生成文档
- 第 46 章 代码不会讲述完整的故事
- 第 47 章 软件文档即指南
- 第 48 章 语境
- 第 49 章 功能性概览
- 第 50 章 质量属性
- 第 51 章 约束
- 第 52 章 原则
- 第 53 章 软件架构
- 第 54 章 外部接口
- 第 55 章 代码
- 第 56 章 数据
- 第 57 章 基础设施架构
- 第 58 章 部署
- 第 59 章 运营和支持
- 第 60 章 决策日志
- 第 61 章 问题
- Part Ⅵ 开发生命周期中的软件架构
- 第 62 章 敏捷和架构的冲突:神话还是现实
- 第 63 章 量化风险
- 第 64 章 风险风暴
- 第 65 章 恰如其分的预先设计
- 第 66 章 初识软件架构
- 第 67 章 问题
- Part Ⅶ 金融风险系统
- 第 68 章 金融风险系统
- Part Ⅷ 附录:技术部落 的软件指南
第 36 章 语境图
给软件系统画图和做文档时,语境图是很有用的起点,让你可以后退一步观察大局。
意图
语境图能帮你回答下面这些问题:
1.我们构建的(或已经构建的)软件系统是什么?
2.谁会用它?
3.如何融入已有的IT环境?
结构
在中间画一个简单的框图展示你的系统,周围是它的用户和其他与之相互作用的系统。比如,对金融风险系统的解决方案就会画出下面这样的图。细节在这里并不重要,因为它是你用来展示系统大局景观的广角视图。重点应该放在人和系统上,而不是技术和协议。
金融风险系统(见附录)的语境图示例
这些示例图展示了这个风险系统,被它的用户和其他所依赖的IT系统围在中间。
用户、演员、角色、人物等
这些是系统的用户。这个风险系统的用户主要有两大类:
业务用户(可以查看生成的风险报告);
管理用户(可以修改风险计算过程所用的参数)。
IT系统
根据不同的环境和选择方案,你可能想要在风险系统语境图上展示的其他IT系统包括:
交易数据系统(金融交易数据源);
参考数据系统(参考数据源);
中心监测系统(警报发往的地方);
活动目录或LDAP(认证和授权用户);
微软SharePoint或其他内容/文档管理系统(分发报告);
微软Exchange(向用户发送电子邮件)。
交互
借助一些关于目标的信息,对标注交互行为(用户 <-> 系统、系统 <-> 系统,等等)非常有用,而不仅仅是由一堆框和意义不明的连接线组成的图。比如,标注用户对系统的交互行为时,我往往会做一张包含重要用例/用户故事的简短符号列表,以此来总结特定类型的用户如何与系统交互。
动机
你可能会问,这么简单的图有什么意义。下面就告诉你为什么它很有用:
使语境更明确,这样就不需要假设;
从一个较高层次展示了正在向已有的IT环境中添加的是什么;
技术和非技术的人员可以当作讨论起点的一种高层次图表;
牵涉到理解系统间接口的问题时,为你识别可能需要沟通的人提供了一个起点。
语境图不会展示太多细节,但确实有助于做好准备工作,是其他图表的起点。最后,画语境图应该只需要几分钟时间,因此真的没有理由不做这件事。
受众
直接的软件开发团队内部人员,外部的技术和非技术人员。
示例
让我们看一个例子。“技术部落”网站1为在泽西岛和格恩西岛(海峡群岛中最大的两个岛屿)寻找与技术、IT和数字领域相关的人、部落(业务、社区、兴趣组等)和内容提供了一个途径。在最基本的层面上,它是一个本地的微博、新闻、博文、活动、讲座、工作以及更多东西的内容聚合器。这是一个提供可视化总结的语境图。
“技术部落”-语境
细节在这里不重要,因为这是你退后一步看到的。重点应该放在人(演员、角色、人物等)和软件系统上,而不是技术、协议和其他底层细节。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论