架构规划方法2016版解读.ppt

再考虑其他纬度进行系统划分，基于UC矩阵进行不同纬度的分析 专业化、平台化角度分析系统划分 从技术架构角度来讲（性能、技术手段、数据容量），系统划分的纬度 TNA、技术相关架构TSA＝＝＝》决定系统划分 DIOA架构 再考虑其他纬度进行系统划分，基于UC矩阵进行不同纬度的分析 专业化、平台化角度分析系统划分 从技术架构角度来讲（性能、技术手段、数据容量），系统划分的纬度 TNA、技术相关架构TSA＝＝＝》决定系统划分 DIOA架构 领域分析方法用于产品级分析设计，识别可重用组件，设计领域级体系架构 产品范围又分电信-移动/固网-… 因此领域分析需要在多个层面进行 内容页 组件分类与普元的对比？ SRM组件分类？ 领域分析方法用于产品级分析设计，识别可重用组件，设计领域级体系架构 产品范围又分电信-移动/固网-… 因此领域分析需要在多个层面进行 领域分析方法用于产品级分析设计，识别可重用组件，设计领域级体系架构 产品范围又分电信-移动/固网-… 因此领域分析需要在多个层面进行 业务服务与集成分立 ESB+统一接口+直连 判断表 业务服务与集成分立 ESB+统一接口+直连 判断表 这个图只能说明流程+数据+应用的分析过程，不包含技术，所以不能用在开头作为整体方法论 领域分析方法用于产品级分析设计，识别可重用组件，设计领域级体系架构 产品范围又分电信-移动/固网-… 因此领域分析需要在多个层面进行 * 验证： 下一层的元素是否来源于上一层 下一层的元素是否和上一层的冲突 * * 按照2009.9.10史进给韩主任汇报时主任的说法，“逻辑设计”阶段 “要素”第一项修改为“逻辑块之间的聚合关系”。 * 第一类是在商业上比较重要的活动，常称为业务流程。 第二类是在商业上不太重要的活动，但必须进行这些活动来保证业务正常运转。系统管理、清洁和安全等工作就是这类活动的示例。该业务用例具有支持的性质。 第三类是管理工作。具有管理性质的业务用例所显示的工作影响如何管理其他业务用例以及该业务和其所有者的关系。 业务为客户提供的主要服务有哪些？ 一种有效的方法是研究客户的生命周期。客户与业务的首次接触是什么？客户经历了业务的哪些阶段或状态？ 具有更多业务支持特征的流程（包括不直接使客户受益的活动）也可以用业务用例来表示。查找以下种类的活动： 人员的发展与维护。 业务内部 IT 的开发与维护。 办公室的设立与维护。 安全性。 法律活动。 具有管理特征的流程可以用业务用例来表示，尽管这些流程通常对于信息系统不具有重要的意义。要查找这些流程，可以先查找与业务的整体管理相关的活动。这种流程通常会与拥有者主角进行交互。考虑拥有者主角将从业务中得到什么。查找以下种类的活动： 为拥有者与投资者开发并提供有关业务的信息。 设定长期的预算目标。 协调业务中的其他用例，并确定其优先级。 在业务中创建新的流程。 监测业务中的流程。 这种流程的生命周期往往会持续一个财政年度。 * 领域分析方法用于产品级分析设计，识别可重用组件，设计领域级体系架构 产品范围又分电信-移动/固网-… 因此领域分析需要在多个层面进行 * * 概念模型的工作 目标：对关键业务实体、实体关系、相关业务规则建模，形成高层次的实体关系图。 寻找并描述与实体类、关系相关的业务规则。 从高层概念引出要分析的核心实体，以及之间的关系 核心实体进行定义，以期大家对某个概念统一认识 将活动按菱形展开，所有的一级的活动全部展开 将从属关系进行描述 将上级的活动分解成更细粒度的二级活动 继续分解，直到分解到直接业务人员不可见为止 分别将业务活动、管理活动、实现层面活动分解到位 注意事项 只分析业务人员角度可见的ER关系 不可以系统中如何设计的角度（系统实现角度）分析ER 活动的展开使用菱形展开方法 实体可以增加核心属性 * * 逻辑设计的工作 在概念模型分析的基础上，设计出展现系统中如何进行实现这一视角的ER模型。 确定系统范围与边界 去除仅仅代表业务概念，而不需要应用系统实现的实体类； 将概念模型中相近的实体进行归纳、分解 按照规范化理论，对数据模型逐步规范化，去除冗余，使模型结构更为清晰、规范； 引入设计层面所需要的实体类，包括为分解多对多关联关系引入的实体类，解决继承关系引入的实体类，增加新的设计实体类； 设计实体类的属性，设计相关的属性域，确定实体类的候选键并进一步确定主键，建立与属性相关的业务规则； 注意 逻辑模型仍然是一个技术中立的模型，逻辑模型的设计不要过多考虑关于性能方面的问题，也不要考虑数据如何分布、存储 最终设计出全属性模型 通过和DFD进行交叉验证找问题 * * 物理设计的工作 物理模型设计是结合具体的数据库管理系统以及应用系统的可实现性、性