文档详情

如何描述软件的架构

野鹰
实名认证
店铺
PDF
451.77KB
约5页
文档ID:13481801
如何描述软件的架构_第1页
1/5

如 何 描 述 软 件 的 架 构 —解读 IEEE Std 1471-2000 主要内容: 1. 背景介绍 2. 架构描述中的概念性模型 3. 相关名词定义 4. 为什么要写概要设计文档(也就是 Architectural Description) 5. 架构设计活动中的通用步骤 6. 后 记 背景介绍 以前写过一些概要设计,总感觉不地道国庆有空在家看了一些书,现在将看书的内容记录下来,一方面以备后用,另外记录的过程也可以加深理解 架构描述中的概念性模型 架构( architecture)这个词来源于建筑学 IT 这个行业中的词汇许多都来源于传统行业传统行业发展了很多年,有一套成熟的理论,而软件设计这个行业才几十年,在实践中,为了提高生产效率和品质,工程化是一个必然化的趋势,于是传统行业工程化的理论和实践就有了在软件设计这个行业移植的可能性 在建筑行业或者机械设计行业,在建筑建造出来或者产品加工出来之前,设计人员 用图纸来表达自己的设计意图当然成熟的设计人员在取得认证之前,需要到施工单位或者到加工车间实习很长时间,以防止设计出来之后,无法建造或加工 如果描述软件的架构,在你对系统架构描述的过程中,需要出现那 些 要素( element) ,这些要素之间又有着怎样的关系? IEEE std 1471-2000 这篇文档给出答案。

下面的图描述了要素之间的关系 图中描述要素之间的关系使用的语言是 UML对 UML 需要专门的时间来解读 UML 已经发展成软件设计描述语言的事实标准 相关名词定义 仔细阅读上面的图,图中的方框表示架构设计文档中需要描述的要素,要素之间的连线表示这些要素之间的关系整个图分 五 层: 第一层: mission 第二层: Environment, System, Architecture 第三层: Stakeholder, Architectural Description, Rationale 第四层: Concern, Viewpoint, View 第五层: Library Viewpoint, Model 不知道大家仔细看过这个图之后是什么感觉,反正我第一次读过这个图之后有一种豁然开朗的感觉如果大家没有这种感觉,我就先来介绍一下这些要素的具体含义 第一层:  Mission:翻译成中文就是任务 ,使命 也就是 为什么我们要做这个系统 可能的原因是为了更大的赢利,市场占有率更高,完善产品系列等等 第二层:  System: 翻译成中文就是系统具体的定义是:一系列组件,组织在一起,相互作用从而完成一个或者一些特殊的功能。

 Environment: 系统不可能单独存在,它总是存在在一个环境之中我们将系统范围之外的东西,对系统有影响,有交互的客观存在定义为环境( Environment) .有时也称为系统的上下文( context)  Architecture:系统架构 每个系统有一个架构无论你是有意设计而形成,或者自发形成 第三层:  System stakeholder:系统利益攸关方 An individual, team, or organization with interests in, or concerns relative to, a system)从图中我们可以看出一个系统有一个到多个利益攸关方  Architectural Description:简称为 AD直译为系统描述从图中我们可以看出,一个系统架构,有一个系统描述和它对应 系统描述是由 stakeholder 来识别出来并整理成文  Rationale: 从字典上查下来的含义是:基本原理,根本原因那么在架构描述文件中要出 现那些“基本原理”和“根本原因” 呢 ?个人以为:  在设计软件架构时,我们做了许多取舍,选择。

我们需要列出 之所以选择 A而不是 B 的理由  架构设计是如何满足功能性需求和非功能性需求 第四层:  Concern: 翻译成中文是关心点,关注点 从图中,我们可以看出 concern 是和stakeholder 联系在一起利益攸关方有一个或多个 concern通常不同的利益攸关方其关注点不尽相同有时甚至是矛盾的抄录一段英文: concerns are those interests which pertain to the system’s development , its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, distribution and evolvability.  Viewpoint:我将它直译成观察点 就是你站在什么地方来看这个系统不同的stakeholder 可能有不同的 concern,从而导致不同的观察点。

 View:我将它直译成视图就是 stakeholder 站在某个观察点,他看到系统是个什么样子视图和观察点一一对应 第五层:  Library Viewpoint:就是一个库,库中存放了前人正对各种系统,各种不同的stakeholder,各种不同的 concern,总结出来的观察点这样可以方便后人来参考使用  Model:直译成模型就是用来表达视图的方法直白地说,就是系统中各种元素是如何组织在一起发挥作用我们用图形化的表示把你看到的东西表达出来 为 什 么 要 写 概 要 设 计 文 档 ( 也 就 是 Architectural Description) 通常这个问题的答案是:领导让我写 写这个文档要花时间,时间就是成本,领导为什么要你写这个文档呢?直接的回答是有许多系统的利益攸关者需要通过你写的文档来看,他的 concern 是否得到满足下面简单罗列写这个文档在整个项目的生命周期中的 作用 : 1. 分析另外一种架构设计的可能直白的说就是 ,我们知道你是这样设计的,是不是那样设计更好呢? 2. 作为一个依据,可以做商务上的规划:从传统的架构设计向新的架构设计迁徙。

3. 在组织内部作为一个沟通的依据 4. 作为开发者和客户在合同谈判时沟通的依据 5. 作为认证架构设计是否合符某个标准的评判依据 6. 作为开发和维护的文档,作为知识库的一 部分可以供后来维护和培训的教材 7. 作为后续开发活动的输入 8. 作为系统实施和基础设施建设的支持文档 9. 作为项目计划和预算的输入文档 10. 作为项目采购文档的输入 11. 供在整个项目生命周期中回顾( review) ,分析和评估 12. 作为一组有共同特征的系统的规格 架构设计活动中的通用步骤 1. 准备 文档 的 格式 通常 一个 文档 中 包含 以下 内容: 1) 发布 日期 和 当前 状态 2) 发布 组织 3) 变更 记录 4) 概要 说明( summary) 5) 范围( scope) 6) 上下 文( context) 7) Glossary 8) References 2. 识别 系统 的 stakeholder 和 他们 的 concerns 通 常 的 系统, 其 stakeholder 至少 应该 包括 人员 和 组织: 1) 系统 的 使用 者 2) 系统 的 客户 3) 系统 的 开发 者 4) 系统 的 维护 者 识别 出来 的 concern 至少 应该 包含 以下 内容: 1) 开发 这个 系统 的 目 的 或者 这个 系统 的 使命( mission) 2) 用来 实现 使命 的 适当 性( 为 何 这个 系统 开发 出来 就 能够 实现 使命 ) 3) 构建 这 个 系统 的 可行性 4) 系统 开发 和 运行 所 蕴藏 的 风险 5) 系统 的 可维护 性 ( maintainability ) , 可 部署 性 (deployability) 和 可 演化 性( evolvability) 3. 选择 系统 架构 的 观察 点 描述 一个 观察 点 至少 包含 以下 内容: 1) 观察 点 的 名 称 2) 该 观察 点 主要 解决 那位 stakeholder 的 concern 3) 该 观察 点 解决 什么 样 的 concern 4) 基于 该 观察 点 在 建立 视图 时 采用 的 建模 语 言, 建模 技术, 分析 方法。

5) 该 观察 点 是否 是 从 那个 观察 点 库 ( library viewpoint) 中 选出 6) 选择 该 观察 点 的 理由 4. 多个 架构 视图 每个 视图 需要 包括 以下 内容: 1) 该 视图 的 标识 和 介绍 性 的 内容 2) 使用 该 视图 对应 的 建模 语言, 方法 建立 系统 的 模型 表示 3) 配 置 信息 ( configuration information, as defined by the using organization) 一个 视图 可以 包含 多个 模型 5. 系 统 多个 视图 之间 的 一致 性 描述 AD( architectural description) 需要 对 多个 视图 之间 的 一致性 进行 分析, 并 记录 多个视图 之间 已 知 的 不一 致 性 6. Architectural rationale 记录 选择 某种 设计 的 理由 后 记 前面 描述 了 概要 设计 中 应该 包含 什么 内容, 但 并没有 描述 通常 我们 会 选 择 什么 样 的viewpoint, 也 没有 描述 通常 选择 什么 样 的 视图 和 模型 来 描述 系统。

需要 知道 业界 通常 的 选择和 这 些 选择 背后 的 理由, 请 看 下 集。

下载提示
相似文档
正为您匹配相似的精品文档