系统架构师的任务

系统架构师的任务
         软件系统架构师在整个项目中领导并协调与 技术相关的活动和制品。从技术、结构、软件系统的组织结构角度调整一些主要设计决定。与RUP中其它角色相比，软件系统架构师更注重广度，而不是深度。
         软件系统架构师要能够在信息不完整的情况下把握问题的本质，并作出合理、关键的决定。
         经验、领导能力（Architect负责技术方面的问题，项目经理负责商业和管理方面的问题）、沟通能力（不能被法规所领导，要由其余团队的意见所领导）、面向目标的工作态度（必须一切以结果为中心，对问题精益法求精的完美主义者不适合担当这个角色）。
         交流：
         在项目经理和开发团队之间建立联系
         在内部成员和涉众之间建立联系（系统体系结构小组和项目小组）
         在不同开发小组之间建立联系（保证架构完整性）
系统架构（Architecture)
         （1）定义
         组成系统的结构元素及它们的接口、元素之间的联系渠道、把这些结构和行为元素组成更大的系统、指导开发组织的架构风格。
         其它：易用性、功能性、性能、可适应性、可复用性、可理解性、权衡经济和技术的约束条件、对美学的关注。
         系统架构师只关注对系统架构具有重要意义的需求和与架构相关的设计决定。
         （2）模型和视图（包括其中的一种或几种）
         logic view(存在于所有系统中），显示软件的所有元素及它们的结构：类、包等。
         process view，存在于分布式系统和并发系统中，显示不同实体间的并行关系及实现通信和保持同步的方式。
         implementation view,显示实现的元素（源代码文件、可执行文件等）在开发环境中的组织方式。
         deployment view，显示不同的运行时构件在运行时如何被复制和交付及它们之间如何通信。
         use-case view，捕获最很重要的需求：对系统架构有重要影响的用例或用例的一部分，还包括非功能性需求。可能还包括用例的实现，以此说明系统的工作方式。
         前4个视图在解决方案空间，后一个在问题空间与前4个建立联系。为4+1视图。
         以下来自于转载资料： http://hi.baidu.com/yayalotus/blog/item/ad792b732dd03a1c8701b0fe.html
         4+1视图包括：逻辑视图（Logic View），开发视图（Develop View），进程视图（Process View），物理视图（Physical View）和场景视图（Scenarios）。
         

         通常我们选择UML来表现各种视图，以下列出了UML和各视图的对应关系

         4+1 视图                                    UML

         场景视图                             use case

         逻辑视图                             类图

         开发视图                             类图，组件图

         进程视图                             无完全对应

         部署视图                             部署图

         在架构设计稳定中通常不会给出较多的用例描述，这些是在需求稳定中定义。但是往往架构文档会选择一些用例，列入文档中，这些用例和一些非功能性需求一起用以证明架构的有效和正确性。在逻辑视图中用例的实现是必不可少的一节，尽管架构设计更关注非功能性需求。

融入MDA的思想

         对于逻辑视图和开发视图所应包含的内容常常会觉得很难区分两者间的明显界限。逻辑视图包含更多的分析模型与实现技术本身相关性应该较少，如业务对象模型及其扩展。而开发视图则会与实现技术紧密相关。

随着MDA思想的推广，在架构设计文档的撰写方面也产生了影响，我们不难把MDA的PIM和逻辑视图联系起来，而把MDA中的PSM和开发视图联系起来。

         在编写逻辑视图是我们应该描述与技术平台无关的模型，而开发视图则描述与实现技术平台相关的模型。如在逻辑视图中表现的某些实体类，我们会在开发视图中转换为EJB组件（实体Bean）。这种做法不仅有利于我们编写架构设计文档，同时更是一种好的架构设计思考流程。（引完）
软件架构文档（SAD）
         RUP中软件架构文档是全面的，架构师做的第一步就要对其进行剪裁。实际的架构要通过架构原型来验证。架构机制代表了对常见问题的通用的、具体的解决方案。它们可能是结构模式、行为模式或两者的结合。另外还有一些附加的结构如指导（guidline)。主要来完成一些制品，如风险列表、项目计划和迭代计划、外貌、需求和用例等。
系统架构师的工作（VRAPS）
         vision：架构外貌在软件架构文档中有详细描述并与项目整体的外貌文档相联系。在RUP细化阶段执行的很多活动都与架构文档相关。
         Rhythm：三重节拍：周期、迭代和创建。
         Anticipation：不同的原则相互影响：好的节奏是使开发人员不断回顾并重新评估系统的架构。
         Partnering：对复用充满热情。
         Simplification：对系统架构和组织环境做出净化。
 系统架构师在RUP中的活动

•  与需求和项目管理相关的活动
  排列用例的优先级、分析架构、创建用于验证架构的原型。
•   细化架构
  识别设计机制、识别设计元素、结合现存的设计元素、结构化实现模型、描述分布和运行时的架构、
•   维护架构的完整性
  开发设计指导、编程指导、回顾架构

在RUP中找到自己的方法
          熟悉一些基本概念：迭代开发、RUP生命周期（阶段和迭代）、风险管理，并理解一些与架构有直接关系的概念：构件和不同的架构视图。查看术语表中的定义是一个可行的办法。
           1、通过RUP角色进入RUP，执行为这个角色定义的各种活动。
            2、从制品开始：软件架构文档（它的模板和示例）。
            3、从Roadmap开始：开发构件解决方案。