架构师的职责及工作描述

1、架构师的职责及工作描述什么叫架构师系统分析员属于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.负责在整个项目中对技术活动和工件进行领导和协调。构

2、架设计师要确立每个构架视图的整 体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口。因此，与其他角 色相比，构架设计师的见解重在广度，而不是深度。架构师负责理解系统的业务需求，并创建合理、完善的系统体系架构。架构师也负责通过 软件架构来决定主要的技术选择。这典型的包括识别和文档化系统的重要架构方面，包括系 统的需求、设计、实现和部署视图。The software architect has overall responsibility for driving the major technical decisions, expressed as the software arch

3、itecture. 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 concern

4、s of the various stakeholders,:注：这就是说架构师要在大家意见不统一的时候给出一个基本的并且这些人都比较能接受 的基本意见，这就是要求架构师要有一定的判断力和决定能力以及体现核心作用、核心力量 和支柱的这样一种领导力。driving down technical risks, and ensuring that decisions are effectively communicated, validated, and adhered to.:注：架构师一定要具备降低风险（当然主要是技术方面）的能力，以及他的这种架构思 想切实得到贯彻和落实的能力。建模软件应用和方

5、案，并创建和管理可重用的模式和模型；维护在我们的软件系统中的系统 组件和他们的接口。建模信息架构，创建和维护组织技术设施的布局，并提供满足业务需求的技术观点和远景。 架构师的技能要求和能力素养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

6、 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 o

7、f 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.-经验：既包括在问题领域的经验（通过彻底了解需求），也包 括在软件工程领域的经验。对于一个构架团队，这些素质要求可由各团队成员来分别承担， 但其中至少要有一名构架设计师能

8、够把握项目的全局。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 techn

9、ical 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

10、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 ma

11、nagement 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 care

12、er 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.-以目标为中心、积极主动，不懈 地追求成效。构架设计师是推动项目发展的技术动力，而不是空想家。在其职业生涯中，成 功的构架设计师一直都要在捉

13、摸不定和承受压力的情况下作出折衷决定。构架设计师只有将 注意力集中在该做的事情上，才能在项目中取得成功。从专业角度看，构架设计师必须具备系统设计员（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 levelmakes broade

14、r 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 architectur

15、e 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-t

16、ime 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 bett

17、er to have these roles performed by separate people, in order to ensure that time pressure on one role doesnt cause the other role to be neglected.注：小型项目架构师可以兼做项目经理。但是不要因为时间安排问题导致两种角色互有影 响。架构师需要对此有很好的调节能力和全局安排、协调处理、解决能力。软件架构模型（4+1） 架构模型软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进 行装配，从而满足系统主要功能和性能需求，并满足其

18、他非功能性需求，如可靠性、可伸缩 性、可移植性和可用性。Perry和Wolfe使用一个精确的公式来表达，该公式由Boehm 做了进一步修改：软件架构=元素，形式，关系/约束软件架构涉及到抽象、分解和组合、风格和美学。我们用由多个视图或视角组成的模型来描 述它。为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图(请对照图1): 逻辑视图(Logical View)，设计的对象模型(使用面向对象的设计方法时)。过程视图(Process View)，捕捉设计的并发和同步特征。物理视图(Physical View)，描述了软件到硬件的映射，反映了分布式特性。开发视图(Development

19、 View)，描述了在开发环境中软件的静态组织结构。架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例(use cases)或场景(scenarios)来说明，从而形成了第五个视图。正如将看到的，实际上软件架 构部分从这些场景演进而来，将在下文中讨论。图1 4+1视图模型注：请特别留意这四个view的各自主要使用对象。比如Development View，主要是 programmers看到的系统架构图。我们在每个视图上均独立地应用Perry & Wolf的公式，即定义一个所使用的元素集合(组 件、容器、连接符)，捕获工作形式和模式，并且捕获关系及约束，将架构与某些需求连接

20、 起来。每种视图使用自身所特有的表示法一蓝图(blueprint)来描述，并且架构师可以对 每种视图选用特定的架构风格(architectural style)，从而允许系统中多种风格并存。我们将轮流的观察这五种视图，展现各个视图的目标：即视图的所关注的问题，相应的架 构蓝图的标记方式，描述和管理蓝图的工具。并以非常简单的形式。4+1”视图模型具有相 当的”普遍性”，因此可以使用其他的标注方法和工具，也可以采用其他的设计方法，特别是 对于逻辑和过程的分解。但文中指出的这些方法都已经成功的在实践中运用过。逻辑结构一面向对象的分解逻辑架构主要支持功能性需求一一即在为用户提供服务方面系统所应该提供的

21、功能。系统 分解为一系列的关键抽象，(大多数)来自于问题域，表现为对象或对象类的形式。它们 采用抽象、封装和继承的原理。分解并不仅仅是为了功能分析，而且用来识别遍布系统各个 部分的通用机制和设计元素。进程架构一过程分解进程架构考虑一些非功能性的需求，如性能和可用性。它解决并发性、分布性、系统完整性、 容错性的问题，以及逻辑视图的主要抽象如何与进程结构相配合在一起一即在哪个控制线程 上，对象的操作被实际执行。进程架构可以在几种层次的抽象上进行描述，每个层次针对不同的问题。在最高的层次上， 进程架构可以视为一组独立执行的通信程序(叫作processes)的逻辑网络，它们分布在 整个一组硬件资源上，

22、这些资源通过LAN或者WAN连接起来。多个逻辑网络可能同时 并存，共享相同的物理资源。例如，独立的逻辑网络可能用于支持离线系统与在线系统的分 离，或者支持软件的模拟版本和测试版本的共存。进程是构成可执行单元任务的分组。进程代表了可以进行策略控制过程架构的层次（即：开 始、恢复、重新配置及关闭）。另外，进程可以就处理负载的分布式增强或可用性的提高而 不断地被重复。软件被划分为一系列单独的任务。任务是独立的控制线程，可以在处理节点上单独地被调度。开发架构一子系统分解开发架构关注软件开发环境下实际模块的组织。软件打包成小的程序块（程序库或子系统）， 它们可以由一位或几位开发人员来开发。子系统可以组织

23、成分层结构，每个层为上一层提供 良好定义的接口。系统的开发架构用模块和子系统图来表达，显示了输出和输入关系。完整的开发架构只 有当所有软件元素被识别后才能加以描述。但是，可以列出控制开发架构的规则：分块、分 组和可见性。大部分情况下，开发架构考虑的内部需求与以下几项因素有关：开发难度、软件管理、重用 性和通用性及由工具集、编程语言所带来的限制。开发架构视图是各种活动的基础，如： 需求分配、团队工作的分配（或团队机构）、成本评估和计划、项目进度的监控、软件重用 性、移植性和安全性。它是建立产品线的基础。物理架构一软件至硬件的映射物 理架构主要关注系统非功能性的需求，如可用性、可靠性（容错性），性

24、能（吞吐量） 和可伸缩性。软件在计算机网络或处理节点上运行，被识别的各种元素（网络、过程、任 务和对象），需要被映射至不同的节点；我们希望使用不同的物理配置：一些用于开发和测 试，另外一些则用于不同地点和不同客户的部署。因此软件至节点的映射需要高度的灵活 性及对源代码产生最小的影响。场景一综合所有的视图四种视图的元素通过数量比较少的一组重要场景（更常见的是用例）进行无缝协同工作，我 们为场景描述相应的脚本（对象之间和过程之间的交互序列）。在某种意义上场景是最重要的需求抽象，它们的设计使用对象场景图和对象交互图来表示。该视图是其他视图的冗余（因此+1），但它起到了两个作用：作为一项驱动因素来发现

25、架构设计过程中的架构元素，这一点将在下文中讨论。作为架构设计结束后的一项验证和说明功能，既以视图的角度来说明又作为架构原型测试的 出发点。视图之间的对应性各种视图并不是完全是正交的或独立的。视图的元素根据某种设计规则 和启发式方法与其他视图中的元素相关联。模型的剪裁并不是所有的软件架构都需要4+1视图。无用的视图可以从架构描述中省略，比如：只 有一个处理器，则可以省略物理视图；而如果仅有一个进程或程序，则可以省略过程视图。 对于非常小型的系统，甚至可能逻辑视图与开发视图非常相似，而不需要分开的描述。场景 对于所有的情况均适用。迭代过程Witt等人为设计和架构指出了 4个阶段：勾画草图、组织、具体化和优化，分成了 12个 步骤7。他们还指出需要某种程度的反向工程。而我们认为对于大型的项目，该方法大，线 性化了。在4个阶段的末尾，可用于验证架构的内容太少。我们提倡一种更具有迭代性 质的方法，即架构先被原形化、测试、估量、分析，然后在一系列的迭代过程中被细化。该 方法除了减少与架构相关的风险之外，对于项目而言还有其他优点：团队合作、培训，加深 对架构的理解，深入程序和工具等等（此处提及的是演进的原形，逐渐发展成为系统，而 不是一次性的试验性的原形）。这