dabusidede的博客

模块与组件从设计上来看，组件强调复用，模块强调职责(内聚、分离)，或者说组件是达到可复用要求的模块。UML

选择 工具箱->更多的工具…->Analysis 便有绘制鲁棒图的工具或者新建图时指定Analysis类型图

模块划分思路自顶向下：水平切分思路——分层。垂直切分思路——功能模块。自底向上：先识别类、后归纳出模块的思路——用例驱动。拍脑袋：需要大量灵感外加一些经验水平切分与垂直切分水平切分称为分层，垂直切分为功能模块（子系统）划分，均属于粗粒度模块划分水平切分+垂直切分才能划分细粒度的模块模块划分4步骤——EDD（封装驱动设计）方法4步骤1.研究需求2.粗粒度分层、3.细粒度划分模块4.用例驱动的模块划分评审和优化细粒度模块划分如何进行步骤3，细粒度模块划分？划分技能：子

描述需求的序列图与描述设计的序列图描述需求的序列图描述需求的序列图把系统看作黑盒，描述系统与外部的交互如何从用例规约构建需求序列图？描述设计的序列图描述设计的序列图由架构师推导出来，描述完成某个用例的系统类间的交互用例驱动的模块划分过程用例驱动的模块划分是自底向上的方式，先推导出类，在划分模块以下使用压缩用例进行示例应用描述需求的序列图，运用鲁棒图，发现用例需要的类你认为压缩就是把原文件变成压缩吧，于是你想出了几个对象你心想，不应该由压缩器直接生成压缩包，于是你加入了打包器，那

分层架构介绍常见模式：展示层，业务层，数据层常见模式：UI层（用户界面层），PD层（问题领域层），DM层（数据管理层），SI层（系统交互层）UI层：于用户打交道PD层：业务领域抽象，领域功能实现DM层：持久化数据SI层：系统间交互如何分层通过分析上下文图，查看与系统交互的外部对象进行分层如：当系统需要与外部系统交互是，我们便考虑添加外部系统访问层...

功能树功能树是需求分析的结果，架构师从需求分析人员哪里获取粗粒度模块划分获取功能树功能树一般位于《软件需求规格说明书（SRS）》中，以目录或画图的方式展示或位于更上游的《方案建议书》中，以功能表的形式展示也可以与需求人员分析自画评审功能树不要被一些不好的功能树所迷惑，有些画的不好的功能树会把操作画成功能项，功能是操作的集合粗粒度模块划分注：功能即用例1.根据功能组来绘画功能的鲁棒图2.分析鲁棒图，合并鲁棒图，合并一些相似的鲁棒图对象，依据鲁棒图划分模块3.完成粗粒度模块划分

原型技术原型技术就是对感兴趣的方面试试看能不能实现原型不实现所有功能，而是实现一小部分功能原型技术分类原型技术分为：水平抛弃原型，水平演进原型，垂直抛弃原型，垂直演进原型水平原型用于演示功能，垂直原型用于验证技术抛弃原型架构验证后被抛弃，演进原型架构验证后被保留水平抛弃原型有时客户并不知道自己想要什么产品，只有看到了产品的基本界面或功能才知道怎么改进，这时应给客户开发一个水平抛弃原型水平抛弃原型可使用织梦，HTML，Word或Photoshop等进行开发水平演进原型水平演进原型并不多见

细化架构设计需要概念架构、需求、领域模型作为输入架构5个视图，15个设计任务对于不同的涉众，我们需求不同的视图，通常划分5个视图，不同的视图有不同的关注点逻辑架构=模块划分+接口定义+领域模型1.设计任务：模块划分首先进行分层，然后划分子系统，最后依据职责划分模块2.设计任务：接口定义协作决定接口，在定义接口前先考虑模型是如何进行交互的3.设计任务：领域模型细化逻辑架构一般设计到模块一级，但以下4种类必须在架构中明确指出，通过参考领域模型细化逻辑架构(1)接口定义类(2)Faca

概念架构是什么概念架构：直指目标的设计思想和重大选择概念架构指定了高层组件和高层组件的交互，概念设计不涉及接口，模块的细节为关键功能需求建立 鲁棒图鲁棒图鲁棒图元素边界对象：与系统交互的人或事物控制对象：系统的动作，行为实体对象：系统的信息用例图与鲁棒图从关键需求建立鲁棒图示例书店搜索系统的鲁棒图创建过程搜索功能我们想到了几个对象，顾客、结果页面、搜索操作、搜寻关键子、搜索结果，于是建立如下鲁棒图获取搜索结果动作根据作者的名字输出Search Results信息Search

关键需求决定架构关键需求包括关键质量需求，关键功能需求，关键约束需求确定关键质量需求关键质量需求与系统所涉及的人群有关，如系统是针对银行，那么安全性会是关键需求，如系统是为普通人群使用，那么鲁棒性可能是关键需求质量需求之间相互影响，如性能与安全不能同时兼顾确定关键功能需求关键功能需求一般是20%~30%的用例核心功能没有这些功能，系统便无法完成业务目标，核心功能需求作为关键功能需求高风险功能高风险需求作为关键功能需求特殊的功能一些特殊的功能，可以作为关键功能需求关键需求确定概念架构

什么是领域模型表达某个业务领域的概念的关系的图，如下：需求人员视角通过领域建模能够促进需求分析，在聆听客户需求时，经常画一些草图作为领域模型基础，当我们了解更多的领域知识是，也就丰富这个领域模型如下，需求分析过程中建立起来的领域模型开放人员视角领域模型作为理解领域知识的手段，因为领域模型很好的展示了概念之间的关系领域模型构建过程示例领城建模小组正在卓有成效地开展着工作…领域专家：项目被分解成许多任务，分配下去。架构师：你是说这个意思吗? (指着图 7-20。)领域专家：正是这样

用例技术族用例技术包括：用例图、用例简述、用例规约、用例实现用例图用例图的元素：参与者、用例参与者：可以是系统，或用户用例：用例是一个动词，是一个动作用例简述对用例简短的说明用例规约对用例详细的说明，包括流程的说明，如下：用例规约虽然详细，但不是每个用例都应该有用例规约，只有在难以理解的用例才需书写用例规约用例实现（不是代码的实现，是业务上的实现）用例实现=协作用例技术族应用场景需求分析需求捕获：用例图+用例简述可以用于需求捕获阶段需求分析：用例图+用例简述可以应

需求怎么来？需求由需求开发而来，需求开发=愿景分析+需求分析愿景分析愿景分析：根据需求方对的系统期望的描述（如，需求方：我希望这个软件能解决不同地区员工的交流问题…），总结出 业务目标+需求范围+特色+上下文图愿景分析得到的文档为《愿景与范围文档》（或称为《市场需求文档》，《项目立项书》）上下文图上下文图描述了待开发的系统与周围所有事物的联系，待开发系统位于中心，保持黑盒状态需求分析需要分析：根据需求方提出想要解决的问题，分析出系统的需求（如，需求方：我希望A员工能快速找到B员工。分析：需

架构设计6个步骤1.需求分析2.领域建模3.确定关键需求4.概念架构设计5.细化架构设计6.架构验证需求分析通过需求分析，我们需要得到功能、质量、约束需求领域建模根据得到的需求，我们进行领域建模，得到领域模型确定关键需求从需求中选择关键的功能需求，关键的质量需求，这些关键需求决定我们架构的大方向概念架构设计根据关键需求，我们设计概念架构，概念架构是我们架构的大方向细化架构设计有了领域模型和概念架构，我们细化我们的概念架构，得到了真正的架构架构验证如果项目够复杂，那我们应

5视图逻辑架构视图不仅包含用户可见的功能，还需包含实现用户功能的辅助功能开发架构视图指定了我们系统的分为多少个程序包，这些程序包采用什么技术（MFC还是c++还是…）,以及程序包采用的第三方SDK，框架等运行架构视图指定系统运行时，程序之间的交互物理架构视图物理架构关注系统的程序如何部署到物理机器上数据架构视图关注数据的存储方案不同涉众所关注的视图程序员、配置管理员：开发结构程序经理、系统分析员、用户：逻辑架构数据库工程师：数据架构部署工程师：物理架构注：对于没有经验的软件架

软件架构为谁而设计为用户设计：使用软件的人，需考虑功能的使用性为客户设计：给我们钱做这个软件的人，考虑客户的约束条件为开发人员设计：考虑开放质量为管理人员设计：项目经理等，需考虑项目的管理，跟进等软件架构视图什么是软件架构视图从某个角度，描述系统的组成的图多组涉众，多个视图对于不同的角色（如客户与程序员），他们掌握的技能不同，因此需要提供不同的视图逻辑架构与物理架构逻辑架构视图与物理架构视图是常用的架构视图逻辑架构：逻辑架构设计任务如下识别功能块规划功能块的接口明确功能块之

软件架构对新产品的作用上承业务目标：下接技术决策：控制复杂性：组织开发：利于迭代开放和增量交付：软件架构对软件产品线开发的作用什么是软件产品线具有公共特性的一系列产品的集合什么是软件产品线架构针对一系列产品设计的通用架构...

关注点分离要分解一个系统，首先我们要有关注点，下面给出3个关注点通过职责划分：例如我们可以将系统划分为展现层（负责展示），业务层（负责业务处理），数据层（负责数据处理）通过通用性划分：可以分为特定应用部分，领域通用部分，技术通用部分，框架属于领域通用部分通过粒度划分：可以分为子系统，模块，类子系统与软件架构一个复杂的系统：系统由子系统组成，子系统由模块组成，模块由类组成（注：如果子系统足够复杂，那么子系统也是用更下级的子系统组成）无论是系统，子系统，模块，如果足够复杂，那么他们都应该有架

软件架构概念软件架构不是指具体代码的实现，而是软件的设计，不会写代码依然可以成为架构师在《软件体系结构》中的定义：组件以及组件之间交互的设计RUP（统一过程）中的定义：重要决策的设计组件以及组件之间交互的设计：MVC架构示例重要决策的设计示例需求：设计设备调试系统调试系统涉及桌面开发（与用户交互）和驱动开发（访问设备），所以分解系统为桌面应用与嵌入式应用交互使用RS232协议，如果这样，那每个开发桌面应用的程序员都必须了解该协议，所以我们将桌面应用分解为...

简介按照惯例，该写教程先说两句，当然重点不是为了让大家更好的了解，而是如果没有一个简介，总感觉不正规本教程主要结束了软件架构的整体过程，教程不一定是 100% 正确，设计难以区分对错，大家要有自己的思考教程来源本教程出自《软件架构设计》书籍，感谢作者前提知识阅读本教程前，你需要了解UML图，了解常规的分层模式，当前，不了解也可以...