高级系统架构师

高级系统架构师

课程内容第一单元：软件架构介绍软件架构师软件架构设计的特点软件生命周期进程典型的架构模式介绍中间件技术介绍组件技术介绍

第四单元：软件架构设计表现层框架设计业务层架构设计数据访问层设计(持久层架构设计)通用服务设计与使用企业集成

第二单元：软件架构设计原则与方法--使用UML进行软件架构设计概述

第五单元：基于SOA (面向服务架构)架构设计SOA服务的设计与原则 Web服务的体系结构

第三单元：设计模式设计模式的本质典型模式介绍设计模式应用

2

第一部分软件架构介绍

一、架构与架构师

软件架构设计的一些特点 处于软件系统建设的上游需求分析架构设计系统设计系统开发测试上线

需要全面考虑多方面的因素对于同一个问题，可以有多种设计结果是在各种制约条件下取得的较好折衷方案科学+经验+艺术“系统架构”往往被滥用

5

软件架构的层次层次Enterprise

特征 关注整个机构、企业所有 IT系统的整体能力 从整体着眼、与业务紧密相关、与IT规划相关

说明最高层，人数极少

Application

负责应用系统的架构，奠定系统建设的基础 关注系统内部的构成和子系统/模块的分划 需要负责与外部相关系统的互联互通 根据应用系统的逻辑架构制定相应的技术实现方式，设计系统的物理架构 负责系统模块的实现机制和详细结构设计 为系统开发建设奠定基础 负责应用系统的信息和数据模型和结构 通常包括数据库模型和结构设计 负责系统的安全架构设计 涉及系统所有层面的安全措施 系统内部、外部的网络拓扑设计 不同建设项目常常有一些特殊需求

系统架构最高层，大型系统需要有一个架构组一个系统建设项目中常常有多个常常由系统工程是担任常常由数据库专家负责需要由安全专家负责，极缺常常由网络集成商负责 6

System/Sub-System Component Data/Information Security Network Others…

软件架构的分类分类概念架构逻辑架构

特征 关注整个机构、企业所有 IT系统的整体能力 从整体着眼、与业务紧密相关、与IT规划相关

说明

系统子系统、模块分划 功能边界的确定 分布式计算系统设计的特点 针对代码开发 与采用的语言、技术平台紧密相关 数据库设计 针对系统硬件部署 与逻辑架构不同 分布式系统有许多特别的性能和安全考虑7

物理架构数据架构部署架构

IT行业的人才结构BA, BC Architect PM System Eng In shortage Worldwide Hard to find in China Demand and supply are largely balanced in

West Under supply in China Becoming over-supplied in the western countries Programmer Similar in China Only experienced ones are on demand System Admin, DBA,… Balanced in western world In shortage in China8

软件架构师 新的职业领域––––重要性日益提升、供不应求正在不断发展和成熟过程中基本上没有正式的大学课程主要由 IT行业中的专家组成

与建筑业的比较–有专业的设计院、设计事务所–有成熟、完整的规范–技术已经成熟，变化与发展缓慢

9

软件架构师的工作 思考、思考、再思考–深入理解、准确把握建设的业务需求–分析所有可见的问题、障碍、风险–充分参考已有的成功方案，降低风险

交流、讨论、博弈、质疑–对构思中的方案不断提出质疑，避免漏洞–广泛听取各层面的意见，开拓思路–反复质疑、逐步完善已有的设计构思

在动工建设之前验证设计方案的正确性

10

软件架构师的知识结构 基础知识–最好要有系统开发全过程经验–对 IT建设生命周期各个环节有深入了解 包括：系统/模块逻辑设计、物理设计、代码开发、项目管理、测试、发布、运行维护、等

–深入掌握1-2种主流技术平台上开发系统的方法–了解多种应用系统的结构–了解架构设计领域的主要理论、流派、框架

特殊知识–深入了解系统建设的业务需求–了解系统的非功能需求和运行维护需求–了解企业 IT公共设施、网络环境、外部系统11

软件架构师的思维方式 基于框架的思维–架构设计的层次(Enterprise, Application, etc)– IT的生命周期(What, Why, Where, How, When, etc)–成功经验以及方法论的指导

合理把握技术细节–把握各个层次应有的内容–合理忽略不应有的技术细节

风险管理意识–采用成功经验、避免不应有的风险

多方位的开放思维–多维度、多方向、包容性、避免排他性–分析、质疑、抽象、归纳–没有绝对好的架构设计，只有相对优秀的方案12

成为软件架构师的途径 软件架构—巨大的知识海洋–门槛相对较高、职业生涯非常长–相对独立于技术的新陈代谢–适合于喜欢学习的人

不断学习、增加积累、注重经验–注意学习方法论、框架–不断增加各种系统架构的知识–经验积累非常重要

在与高手和同行合作中提高水平–与高手的合作是最佳途径–同行之间的交流也非常有效–在每一个项目中进行创新13

二、软件架构的开发

架构的产生 架构受涉众的影响架构受开发组织的影响架构受设计师的素质和经验的影响架构受技术环境的影响影响架

构的其他因素架构对诸影响因素的反作用

15

软件过程和架构的商业周期 为系统构建一个商业案例理解系统需求创建或选择架构将架构编成文档，并与有关各方进行交流对此架构进行分析和评价根据此架构实现系统保证系统实现符合架构的要求

16

架构的形成 架构的设计应该有一位设计师来完成或者由一个在某位设计师领导下的小组来完成。 设计师(或架构小组)应全面掌握系统的功能需求，并且应有一份所设计架构应满足的划分了优先级的质量属性列表 架构的文档应该完备，至少应该有一个静态视图和一个动态视图，应该采用所有人员认可的文档形式，以保证所有涉众都能很容易地理解这些文档 应该把架构设计方案交由各涉众传阅，应该让各涉众积极参与设计方案的评审 应该对架构认真进行分析，得出可应用的量化度量指标 架构的设计应有助于增量实现 允许架构带来一定的资源增用，但因该清楚地给出这些资源增用的解决方案

17

架构的形成 架构应采用定义良好的模块，各模块的功能责任划分应基于信息隐藏和相互独立的原则。信息隐藏模块应该包括那些封装了计算基础结构特性的模块，以将大部分软件和计算机出结构的变化隔离开 应该是用特定与每个属性的众所周知的架构技术来实现质量属性 架构绝不可以依赖于某个特定版本的商业产品或工具 应将产生数据和使用数据的模块分离开 对于并行处理系统，架构应该采用良好的进程或任务，它们未必反映模块分解结构 每个任务或进程的编写都要考虑到与特定处理器的关系，并保证能够方便地改变这种关系 架构应该采用少量的，简单的交互模式。即在整个运行过程中，系统的功能应该保持一致。这可使系统易于理解，有助于缩短开发时间，提高可靠性、增强可修改性。18

系统质量属性 功能性在很大程度上是独立于结构的 必须在从设计、实现到部署的整个过程中考虑质量属性的实现 对所关心的许多系统质量属性的实现而言，架构具有重要意义 架构并不能独自实现质量属性，它提供了实现质量属性的基础

19

系统的质量属性：–可用性、可维护性、性能、安全、可测试性和易用性

受架构影响的商业属性 架构本身的属性：–概念完整性、易构性

20

系统属性：性能解决方案 资源消耗 锁时间–资源争用–资源的可用性–对其他计算的依赖

资源需求––––––提高计算率减少计算开销管理事件率控制采样频率限制执行时间限制队列大小21

资源管理–引入并发–维持数据或计算的多个副本–增加可用资源

资源仲裁–––– FIFO固定优先级调度动态优先级调度静态调度

22

系统属性：安全性解决方案 抵抗攻击–––––对用户进行身份验证对用户进行授权维护数据的机密性维护完整性限制暴露的信息

限制访问 从攻击中恢复

23

商业质量属性 上市时间成本和收益所希望的系统生命期的长短目标市场推出计划与老系统的集成

24

架构的质量属性 概念完整性 正确性和完整性 可构建性

25

软件架构设计过程举例 应用系统逻辑架构设计–目标：提供系统架构方案、满足业务需求、为物理设计提供依据。

主要环节–根据系统主要的应用场景，确定系统概念架构–调研已有的成功参考架构(RA)和相关模式–提出系统逻辑架构，包括分层的整体逻辑架构、子系统/模块组成以及边界划分根据–讨论逻辑架构的依据、优缺点、以及已经考虑和参考的其他方案–设计相关子架构，包括：数据架构、子系统架构、安全架构、网络架构、等–验证架构设计、确认能够满足业务需求和其他关键指标，如性能要求、费用限制、等。

26

MS Application Reference Architecture

27

MS e-Gov Architecture Framework

28

三、软件开发过程

软件开发过程介绍 RUP XP Agile CMMI MSF

30

统一软件开发过程RUP Rational Unified Process(简称RUP)是一套软件工程过程 RUP是文档化的软件工程产品 RUP是一套软件工程方法的框架–可根据自身的实际情况，以及项目规模对RUP进行裁剪和修改，以制定出合乎需要的软件工程过程。

RUP吸收了多种开发模型的优点，具有很好的可操作性和实用性 RUP最佳软件开发实践––––––迭代式开发管理需求使用以组件为中心的软件架构可视化建模验证软件质量控制变更

31

用例驱动的迭代过程Inception Elaboration Construction Transition

Iteration 1

Iteration 2

Iteration 3

“Mini-Waterfall” ProcessIteration Planning Rqmts Capture Analysis& Design Implementation Test Prepare Release

32

迭代式开发的风险规避

33

分层架构 (Layered Architecture)各种特定的应用系统 Application systems不同应用系统

应用开发人员使用的组件 Domain specific component systems Non-domain specific component systems System software platform通用组件，如GUI创建器、与DBMS的接口、操作系统服务、ORB, OLE组件等操作系统、DBMS、OLE、基础类库等

34

可视化建模

可视化建模提高了抽象的水平35

软件开发生生命周期的二维空间

36

时间维从组织管理的角度描述

整个软件开发生命周期，是 RUP的动态组成部分–可进一步描述为周期 ( Cycle )、阶段 ( phase )、迭代 (Iteration)

核心工作流从技术角度描述RUP的静态组成部分–可进一步描述为行为(activities)、工作流(workflow)、产品(artifact)、工作者(worker)

不同的工作流在不同的时间段内工作量不同 RUP把要开发的系统根据各功能使用的情况划分多个Use Case,并采用迭代的思想把系统的风险分布在四个阶段–风险越大的迭代越要放在靠前的阶段做，使软件产品的风险不断降低–按照RUP的开发模式一般可以达到CMM2、3级的水平37

4+1视图结构模型Logical ViewFunctionality

Implementation ViewSoftware Management Reuse,Portability

最终用户

Use Case ViewUnderstandability Usability

软件工程者

Process ViewPerformance Availablity Fault Tolerance

Deployment ViewPerformance Availablity Fault Tolerance Scalability Delivery and Installation

系统集成者

系统工程者38

本文来源：https://www.bwwdw.com/article/oaii.html