架构师的职责及工作描述

 

什么叫架构师
      系统分析员属于Analyst角色组合，与其相比，架构师则是属于Developer 角色组里的一个角色，一个非常重要的角色。

架构师的职责及工作描述

The software architect role is responsible for the software architecture, which includes the key technical decisions that constrain the overall design and implementation for the project.
负责在整个项目中对技术活动和工件进行领导和协调。构架设计师要确立每个构架视图的整体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口。因此，与其他角色相比，构架设计师的见解重在广度，而不是深度。
 架构师负责理解系统的业务需求，并创建合理、完善的系统体系架构。架构师也负责通过软件架构来决定主要的技术选择。这典型的包括识别和文档化系统的重要架构方面，包括系统的需求、设计、实现和部署"视图"。
The software architect has overall responsibility for driving the major technical decisions, expressed as the software architecture. This typically includes identifying and documenting the architecturally significant aspects of the system, including requirements, design, implementation, and deployment "views" of the system.
The architect is also responsible for providing rationale for these decisions, balancing the concerns of the various stakeholders,
：注 :这就是说架构师要在大家意见不统一的时候给出一个基本的并且这些人都比较能接受的基本意见，这就是要求架构师要有一定的判断力和决定能力以及体现核心作用、核心力量和支柱的这样一种领导力。
driving down technical risks, and ensuring that decisions are effectively communicated, validated, and adhered to.
：注：  架构师一定要具备降低风险（当然主要是技术方面）的能力，以及他的这种架构思想切实得到贯彻和落实的能力。
建模软件应用和方案，并创建和管理可重用的模式和模型；维护在我们的软件系统中的系统组件和他们的接口。
建模信息架构，创建和维护组织技术设施的布局，并提供满足业务需求的技术观点和远景。
架构师的技能要求和能力素养

In summary, the software architect must be well-rounded, posses maturity, vision, and a depth of experience that allows for grasping issues quickly and making educated, critical judgment in the absence of complete information. More specifically, the software architect, or members of the architecture team, must combine these skills:
构架设计师必须多才多艺、成熟练达、洞察力强、经验丰富。这样，他才能在无法获得完整信息的情况下迅速领会问题并根据经验作出审慎的判断。更准确地说，构架设计师（或者构架团队的成员）必须兼具以下技能：

Experience in both the problem domain, through a thorough understanding of the requirements, and the software engineering domain. If there is a team, these qualities can be spread across the team members, but at least one software architect must provide the global vision for the project.· 经验：既包括在问题领域的经验（通过彻底了解需求），也包括在软件工程领域的经验。对于一个构架团队，这些素质要求可由各团队成员来分别承担，但其中至少要有一名构架设计师能够把握项目的全局。

Leadership in order to drive the technical effort across the various teams, and to make critical decisions under pressure and make those decisions stick. To be effective, the software architect and the project manager must work closely together, with the software architect leading the technical issues and the project manager leading the administrative issues. The software architect must have the authority to make technical decisions.· 领导才能：能够推动各个团队的技术进展，并能在压力下作出关键性的决策然后将其贯彻到底。要提高效率，构架设计师和项目经理必须紧密协作。构架设计师主要负责解决技术问题，项目经理主要负责解决行政管理问题。构架设计师必须有权在技术问题上作出决定。

Communication to earn trust, to persuade, to motivate, and to mentor. The software architect cannot lead by decree, only by the consent of the rest of the project. In order to be effective, the software architect must earn the respect of the project team, the project manager, the customer, and the user community, as well as the management team.· 沟通：能够赢得他人的信任，以对其进行说服、激励和指导。构架设计师不能靠命令进行领导，而必须要赢得项目中其他人员的赞同。为了提高效率，构架设计师必须赢得项目团队、项目经理、客户、用户群体以及管理团队的尊敬。

Goal-orientation and Pro-activity with a relentless focus on results. The software architect is the technical driving force behind the project, not a visionary or dreamer. The career of a successful software architect is a long series of sub-optimal decisions made in uncertainty and under pressure. Only those who can focus on doing what needs to be done will be successful in this environment of the project.· 以目标为中心、积极主动，不懈地追求成效。构架设计师是推动项目发展的技术动力，而不是空想家。在其职业生涯中，成功的构架设计师一直都要在捉摸不定和承受压力的情况下作出折衷决定。构架设计师只有将注意力集中在该做的事情上，才能在项目中取得成功。
从专业角度看，构架设计师必须具备系统设计员（designer）的所有能力。但是：
However, unlike the designer, the software architect:
tends to be a generalist rather than a specialist, knowing many technologies at a high level rather than a few technologies at the detail level
makes broader technical decisions, and therefore broad knowlege and experience, as well as communication and leadership skills, are key.

注 : 此处两点，一语道破架构师和设计师的本职区别。请认真体会，侧重点是不同的。
架构师应该能 够：  理解企业应用的体系结构，能够对分布式企业应用系统体系结构、面向服务的应用系统体系结构的设计要点给出指导性建议的。

团队里架构师配备的方法和指导原则
If the project is large enough to warrant an architecture team, the goal is to have a good mix of talents, covering a wide spectrum of experience and sharing a common understanding of software engineering process. The architecture team need not be a committee of representatives from various teams, domains or contractors. Software architecture is a full-time function, with staff permanently dedicated to it.
如果项目较大，需要组建一个构架团队，则应尽量广聚贤才，使该团队既拥有广泛的经验，又对软件工程流程具有一致的认识。构架团队不应该是由各团队、领域或承包商的代表组成的委员会。软件构架设计是一项长期的工作，始终都需要配备专职人员。
For smaller projects, a single person may act as both project manager and software architect. However, if at all possible, it is better to have these roles performed by separate people, in order to ensure that time pressure on one role doesn't cause the other role to be neglected.
注 : 小型项目架构师可以兼做项目经理。但是不要因为时间安排问题导致两种角色互有影响。架构师需要对此有很好的调节能力和全局安排、协调处理、解决能力。

软件架构模型（4+1）
架构模型
软件架构用来处理软件高 层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移 植性和可用性。Perry 和 Wolfe 使用一个精确的公式来表达，该公式由 Boehm 做了进一步修改：
软件架构 ＝ {元素，形式，关系/约束}
软件架构涉及到抽象、分解和组合、风格和美学。我们用由多个视图或视角组成的模型来描述它。为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图（请对照图 1）：
逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
过程视图（Process View），捕捉设计的并发和同步特征。
物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
开发视图（Development View），描述了在开发环境中软件的静态组织结构。
架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例 （use cases）或场景(scenarios)来说明，从而形成了第五个视图。正如将看到的，实际上软件架构部分从这些场景演进而来，将在下文中讨论。
图 1 － "4＋1"视图模型
注： 请特别留意这四个view的各自主要使用对象。比如Development View，主要是programmers 看到的系统架构图。
我 们在每个视图上均独立地应用 Perry & Wolf 的公式，即定义一个所使用的元素集合（组件、容器、连接符），捕获工作形式和模式，并且捕获关系及约束，将架构与某些需求连接起来。每种视图使用自身所特 有的表示法－蓝图（blueprint）来描述，并且架构师可以对每种视图选用特定的架构风格（architectural style），从而允许系统中多种风格并存。
我们将轮流的观察这五种视图，展现各个视图的目标：即视图的所关注 的问题，相应的架构蓝图的标记方式，描述和管理蓝图的工具。并以非常简单的形式。"4+1"视图模型具有相当的"普遍性"，因此可以使用其他的标注方法和工具，也可以采用其他的设计方法，特别是对于逻辑和过程的分解。但文中指出的这些方法都已经成功的在实践中运用过。
逻辑结构——面向对象的分解
逻 辑架构主要支持功能性需求――即在为用户提供服务方面系统所应该提供的功能。系统分解为一系列的关键抽象，（大多数）来自于问题域，表现为对象或对象类的 形式。它们采用抽象、封装和继承的原理。分解并不仅仅是为了功能分析，而且用来识别遍布系统各个部分的通用机制和设计元素。

进程架构——过程分解
进程架构考虑一些非功能性的需求，如性能和可用性。它解决并发性、分布性、系统完整性、容错性的问题，以及逻辑视图的主要抽象如何与进程结构相配合在一起－即在哪个控制线程上，对象的操作被实际执行。
进程架构可以在几种层次的抽象上进行描述，每个层次针对不同的问题。在最高的层次上，进程架构可以视为一组独立执行的通信程序（叫作 "processes"）的逻辑网络，它们分布在整个一组硬件资源上，这些资源通过 LAN 或者 WAN 连接起来。多个逻辑网络可能同时并存，共享相同的物理资源。例如，独立的逻辑网络可能用于支持离线系统与在线系统的分离，或者支持软件的模拟版本和测试版 本的共存。
进程是构成可执行单元任务的分组。进程代表了可以进行策略控制过程架构的层次（即：开始、恢复、重新配置及关闭）。另外，进程可以就处理负载的分布式增强或可用性的提高而不断地被重复。
软件被划分为一系列单独的任务。任务是独立的控制线程，可以在处理节点上单独地被调度。

开发架构——子系统分解
开发架构关注软件开发环境下实际模块的组织。软件打包成小的程序块（程序库或子系统），它们可以由一位或几位开发人员来开发。子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。
系统的开发架构用模块和子系统图来表达，显示了"输出"和"输入"关系。完整的开发架构只有当所有软件元素被识别后才能加以描述。但是，可以列出控制开发架构的规则：分块、分组和可见性。
大部分情况下，开发架构考虑的内部需求与以下几项因素有关：开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制。开发架构视图是各种活 动的基础，如：需求分配、团队工作的分配（或团队机构）、成本评估和计划、项目进度的监控、软件重用性、移植性和安全性。它是建立产品线的基础。
物理架构——软件至硬件的映射
物 理架构主要关注系统非功能性的需求，如可用性、可靠性（容错性），性能（吞吐量）和可伸缩性。软件在计算机网络或处理节点上运行，被识别的各种元素（网 络、过程、任务和对象），需要被映射至不同的节点；我们希望使用不同的物理配置：一些用于开发和测试，另外一些则用于不同地点和不同客户的部署。因此软件 至节点的映射需要高度的灵活性及对源代码产生最小的影响。

场景——综合所有的视图
四种视图的元素通过数量比较少的一组重要场景（更常见的是用例）进行无缝协同工作，我们为场景描述相应的脚本（对象之间和过程之间的交互序列）。
在某种意义上场景是最重要的需求抽象，它们的设计使用对象场景图和对象交互图来表示。
该视图是其他视图的冗余（因此"＋1"），但它起到了两个作用：
作为一项驱动因素来发现架构设计过程中的架构元素，这一点将在下文中讨论。
作为架构设计结束后的一项验证和说明功能，既以视图的角度来说明又作为架构原型测试的出发点。
视图之间的对应性 各种视图并不是完全是正交的或独立的。视图的元素根据某种设计规则和启发式方法与其他视图中的元素相关联。
模型的剪裁
并不是所有的软件架构都需要"4＋1"视图。无用的视图可以从架构描述中省略，比如： 只有一个处理器，则可以省略物理视图；而如果仅有一个进程或程序，则可以省略过程视图。 对于非常小型的系统，甚至可能逻辑视图与开发视图非常相似，而不需要分开的描述。场景对于所有的情况均适用。
迭代过程
Witt 等人为设计和架构指出了 4 个阶段：勾画草图、组织、具体化和优化，分成了 12 个 步骤7。他们还指出需要某种程度的反向工程。而我们认为对于大型的项目，该方法太"线性 化"了。在 4 个阶段的末尾，可用于验证架构的内容太少。我们提倡一种更具有迭代性质的方法，即架构先被原形化、测试、估量、分析，然后在一系列的迭代过程中被细化。该 方法除了减少与架构相关的风险之外，对于项目而言还有其他优点：团队合作、培训，加深对架构的理解，深入程序和工具等等（此处提及的是演进的原形，逐渐发 展成为系统，而不是一次性的试验性的原形）。这种迭代方法还能够使需求被细化、成熟化并能够被更好地理解。
场景驱动（scenario-driven）的方法
系统大多数关键的功能以场景（或 use cases）的形式被捕获。关键意味着：最重要的功能，系统存在的理由，或使用频率最高的功能，或体现了必须减轻的一些重要的技术风险。
开始阶段:
基于风险和重要性为某次迭代选择一些场景。场景可能被归纳为对若干用户需求的抽象。
形成"稻草人式的架构"。然后对场景进行"描述"，以识别主要的抽象（类、机制、过程、子系统），如 Rubin 与 Goldberg6 所指出的 ―― 分解成为序列对（对象、操作）。
所发现的架构元素被分布到 4 个蓝图中：逻辑蓝图、进程蓝图、开发蓝图和物理蓝图。
然后实施、测试、度量该架构，这项分析可能检测到一些缺点或潜在的增强要求。
捕获经验教训。
循环阶段:
下一个迭代过程开始进行：
重新评估风险，
扩展考虑的场景选择板。
选择能减轻风险或提高结构覆盖的额外的少量场景，
然后:
试着在原先的架构中描述这些场景。
发现额外的架构元素，或有时还需要找出适应这些场景所需的重要架构变更。
更新4个主要视图：逻辑视图、进程视图、开发视图和物理视图。
根据变更修订现有的场景。
升级实现工具（架构原型）来支持新的、扩展了的场景集合。
测试。如果可能的话，在实际的目标环境和负载下进行测试。
然后评审这五个视图来检测简洁性、可重用性和通用性的潜在问题。
更新设计准则和基本原理。
捕获经验教训。
终止循环
为了实际的系统，初始的架构原型需要进行演进 。较好的情况是在经过 2 次或 3 次迭代之后，结构变得稳定：主要的抽象都已被找到。子系统和过程都已经完成，以及所有的接口都已经实现。
接下来则是软件设计的范畴，这个阶段可能也会用到相似的方法和过程。
注：请注意区分架构设计和软件设计在过程当中的先后次序关系。

4+1视图允许不同的"风险承担人"找出他们就软件架构所关心的问题。系统工程师首先接触物理视图，然后转向进程视图；最终用户、顾客、数据分析专家从逻辑视图入手；项目经理、软件配置人员则从开发视图来看待"4＋1"视图。