EagleBear2002 的博客

防御式编程 Defensive Programming

可用、正确和优秀的代码

1. 编写大多数情况下都能用（可用）的代码很容易：但是提供意外输入会崩溃。
2. 正确的代码绝不会崩溃
   1. 但所有可能输入集合很大，难以测试
   2. 并非所有正确的代码都是优秀的代码：可能逻辑难以理解，并且几乎无法维护。
3. 优秀的代码是健壮的、高效的、当然也是正确的：即便面对不常见输入，产品级代码也不会崩溃和产生错误的结果。

编程中的常见设想

1. 这个函数"绝不会"被那样调用：传递给我的参数总是有效的
2. 这段代码肯定会"一直"正常运行：它绝对不会产生错误
3. 如果我把这个变量标记为"仅限内部使用"，就没有人会尝试访问这个变量
4. 进行防御式编程时，不应该做任何设想！

Note: this is a simplified and generalized description of a real system

Introduction

The Call Center Customer Care System has been developed by Andersen Consulting for a large US telecommunication company. The primary function of the system is to support interactions with the customers that request new services (ex: new phone lines), changes in the configuration of the existing services (ex: phone number changes, long-distance company changes, or relocation), or report problems.

The phone company has over 19Mil customers. Considering how often, on average, a customer changes his/her service configuration, the system has to support up to 400 company representatives simultaneously at near 7X24 availability level. However, these representatives are not the only means by which a customer can request a change or report problems. For example, there exists a phone service (Quick Service) by which customers can communicate with the system. This is discussed in more detail later.

呼叫中心客户服务系统是由 Andersen Consulting 为美国一家大型电信公司开发的。系统的主要功能是支持与请求新服务（例如：新电话线）、现有服务配置更改（例如：电话号码更改、长途公司更改或搬迁）的客户的交互，或报告问题。

这家电话公司拥有超过 1900 万客户。考虑到客户平均多久更改一次他/她的服务配置，系统必须同时支持多达 400 名公司代表，且可用性水平接近 7X24。但是，这些代表并不是客户可以请求更改或报告问题的唯一方式。例如，存在一种电话服务（Quick Service），客户可以通过它与系统进行通信。稍后将对此进行更详细的讨论。

Architecturally Significant Requirements

1. 架构攸关的需求（ASR）是对体系结构产生深远影响的要求-如果没有这样的要求，体系结构可能会发生巨大的变化。An Architecturally Significant Requirement (ASR) is a requirement that will have a profound effect on the architecture - the architecture might well be dramatically different in the absence of such a requirement.
2. QA 需求越困难和重要，就越有可能显着影响体系结构，从而成为 ASR。The more difficult and important the QA requirement, the more likely it is to significantly affect the architecture, and hence to be an ASR.
3. 如何系统地识别将影响 ASR 和其他因素？How to systematically identify the ASRs and other factors that will shape the architecture?
   1. 从需求文档中收集 ASR Gathering ASRs from requirements documents
   2. 通过采访涉众来收集 ASR Gathering ASRs by interviewing stakeholders
   3. 通过了解业务目标来收集 ASR Gathering ASRs by understanding the business goals
   4. 在项目树中管理 ASR Capturing ASRs in a utility tree

Gathering ASRs from Requirements Documents

1. 无论是使用“MoSCoW”样式指定需求还是作为“用户故事”的集合来指定需求，这些都不能帮助您确定质量属性。Whether requirements are specified using the "MoSCoW" style or as a collection of "user stories", neither of these is much help in nailing down quality attributes.
2. MoSCoW 样式：https://blog.csdn.net/cheny_com/article/details/6358456，使用四个级别来定义一个需求的优先级程度
3. 需求文档通常会以两种方式使架构师失败：Requirements documents often fail an architect in two ways:
   1. 需求规范中的大多数内容都不会影响体系结构。Most of what is in a requirements specification does not affect the achitecture.
      1. 系统应模块化 The system shall be modular
      2. 系统应显示出高易用性 The system shall exhibit high usability
      3. 系统应满足用户的性能期望 The system shall meet users' performance expectations
   2. 对架构师有用的大部分内容甚至都没有出现在最佳需求文档中 Much of what is useful to an architect is not in even the best requirements document.
      1. 在收购环境中，需求文档代表的是收购方的利益，而不是开发商的利益。In an acquisition context, the requirements document represents the interests of the acquirer, not that of the developer.
4. 如果某项要求影响了关键体系结构设计决策的制定，那么根据定义，它就是 ASR。If a requirement affects the making of a critical architectural design decision, it is by definition an ASR.

Gathering ASRs by Interviewing Stakeholders

Document Architecture

Why to document software architecture?

1. 这是记录软件架构的几个很好的理由，例如：There are several good reasons for documenting software architecture such as:
   1. 交流和社交化架构设计决策 Communicating and socialising architecture design decisions
   2. 帮助理解和评估架构设计决策 Helping understand and assess architecture design decisions
   3. 刷新设计师对某些决策的记忆 Refreshing designers' memories about certain decisions
   4. 培训架构设计人员 Training people in designing architecture
   5. 支持地理位置分散的团队 Supporting geographically ditributed teams
2. 体系结构文档用于以下活动：Architecture documentation is used for several activities:
   1. 架构设计分析 Architecture design analysis.
   2. 工作分解和分配 Work breakdown and assignment.
   3. 部署后维护 Post-deployment maintenance.
3. 软件体系结构文档提供了维护和修改决策的框架 Software architecture documentation provides a framework for maintenance and modification decisions.

Challenges in documenting architecture

1. 没有普遍接受的记录软件架构的标准或方法。No universally accepted standard or method of documenting software architecture.
2. 记录大型系统的架构可能是一项耗时且重要的任务。 Documenting architecture of large-scale system can be time consuming and non-trivial task.
3. 对用于记录架构的视图的数量和性质没有达成共识 - 资源密集型活动。No consensus on the number and nature of views used to document architecture-resource intensive activity.
4. 迫在眉睫的最后期限和不断发展的架构性质不利于架构文档的流通。Looming deadlines and evolving nature of architecture are detrimental to the currency of architecture documentation.
5. 缺乏全面的符号和工具。Absence of a comprehensive notation and tooling.

Architectural Pattern

1. 架构模式是一组架构设计决策，适用于重复出现的设计问题，并进行了参数化处理以解决出现该问题的不同软件开发环境。An architectural pattern is a set of architectural design decisions that are applicable to a recurring design problem, and parameterized to account for different software development contexts in which that problem appears.
2. 体系结构模式与 DSSA 相似，但适用于较低级别，范围更窄。Architectural patterns are similar to I SSAs but applied at a lower level" and within a much narrower scope.
3. 课本 227 页

Domain-Specific Software Architecture

1. 领域特定的软件体系结构（DSSA）是软件组件的组合 Domain-Specific Software Architectures (DSSA) is an assemblage of sottware components
   1. 专用于特定类型的任务（域） specialized for a particular type of task (domain) generalized for effective use across that domain, and
   2. 普遍适用于该领域的有效使用 composed in a standardized structure (topology)
   3. 有效构建成功应用程序的标准化结构（拓扑）组成 effective for building successful applications.
2. DSSA 是最大限度地重用知识和进行先期开发并因此开发新的体系结构设计的卓越手段。DSSAs are the pre-eminent means for maximal reuse of knowledge and prior development and hence for developing a new architectural design.

Course Logistics

Why Study Software Design & Architecture?

1. 软件（IT）系统无处不在 Software(IT) systems are everywhere
2. 每个软件密集型（组成的）系统都有一个软件设计和体系结构 Every software intensive system has a software design and architecture
3. 软件设计和体系结构是实践，教育和研究中越来越重要的领域 Software design and architecture are an increasingly important area of practice, education, and research
4. 专业：软件架构师 As a profession: Software Architect
5. 作为研究领域 As a research area
   1. 最初于 1960 年左右开始 Originally started around 1960
   2. 自 1990 年以来备受关注 Attracting major attention since 1990
6. 本课程是关于 This course is about
   1. 软件设计和体系结构的概念，原理，方法和模式 Concepts, principles, methods, and patterns of software design and architecture
   2. 软件设计和体系结构的最新实践 State-of-the-art practices of software design and architecture

Learning Objectives

1. 理解软件设计和体系结构的概念和原理 Understand concepts and principles of software design and architecture
2. 通过考虑需求或通过反向体系结构来创建软件体系结构 Create software architecture by taking requirements or through reverse architecting
3. 在创建软件体系结构和设计的时候应用设计模式、风格、中间件技术和框架 Apply tactics, patterns, styles, middleware technologies and frameworks in creating software architecture and design
4. 系统地分析软件设计和评估软件体系结构 Analyze software design and evaluate software architecture systematically
5. 理解艺术式的设计是如何应用到软件设计与体系结构中的 Understand state-of the-art methods applied in software design and architecture
6. 理解软件设计与软件体系结构之间的关系，以及其他软件工程的领域话题 Understand relationships between software design and software architecture, and other software engineering topic areas

Software Architecture

软件架构是结构和系统结构，包含了软件元素、这些组件的外部可视化属性以及他们之间的关系。Software Architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of these components, and the relationship among them.（In practice 书中的定义）

单独的盒式模型不是架构，但是是一个开始的点 Box-and-line drawings alone are not architecture, but a starting point.

架构包含了组件的行为 Architecture includes behaviour of components.

Role of Architecture

本文对校史博物馆提供的解说词进行了如下修改：

1. 对部分专有名词进行注解；
2. 对部分史实漏错加以订正；
3. 对个别不通顺不正式的表达和错别字进行订正；
4. 对部分未提及的重要事实和讲解重点加以补充。

序厅

这是 2002 年南大百年校庆时确立的校训“诚朴雄伟，励学敦行”。它激励全体南大人：为人、为学要以诚为本、朴实无华，要志存高远、大雄无畏，要勤奋求学、不断开拓创新。

这是校友江泽民在中南海接待八位南京中央大学校友的苏绣“高山流水校友情”。苏州姚建萍刺绣研究所请了 38 个绣娘、用了五公斤丝线，用时四个多月完成这份作品，其价值超 380 万元，由南京大学苏州校友会捐赠。

正厅两边的走廊名为“时光长廊”，展示了南大及其前身各个时期的主要建筑及师生合影。

政治经济学家说：劳动是一切财富的源泉。其实劳动和自然界一起才是一切财富的源泉，自然界为劳动提供材料，劳动把材料变为财富。但是劳动还远不止如此。它是整个人类生活的第一个基本条件，而且达到这样的程度，以致我们在某种意义上不得不说：劳动创造了人本身。

在好几十万年以前，在地质学家叫作第三纪的地球发展阶段的某个还不能确切肯定的时期，据推测是在这个阶段的末期，在热带的某个地方——大概是现在已经沉入印度洋底的一片大陆，生活着一种特别高度发展的类人猿。达尔文曾经向我们大致地描述了我们的这些祖先：它们满身是毛，有须和尖耸的耳朵，成群地生活在树上。

这些猿类，大概首先由于它们的生活方式的影响，使手在攀援时从事和脚不同的活动，因而在平地上行走时就开始摆脱用手帮助的习惯，渐渐直立行走。这就完成了从猿转变到人的具有决定意义的一步。

现在还活着的一切类人猿，都能直立起来并且单凭两脚向前移动。但是它们只是在迫切需要的时候才这样做，并且非常不灵便。它们自然的走法是半直立的姿势，而且需要用手来帮助。大多数的类人猿是以捏成拳头的手的指节骨支撑在地上，两脚蜷起，使身体穿过长臂之间前进，就象跛子撑着两根拐杖行走一样。一般讲来，我们现在还可以在猿类中间观察到从四肢行走到两脚行走的一切过度阶段。但是一切猿类都只是在不得已的时候才用两脚行走。

如果说我们遍体长毛的祖先的直立行走，一定是首先成为惯例，而后来才渐渐成为必然，那末必须有这样的前提：手在这个时期已经愈来愈多地从事于其他活动了。在猿类中，手和脚的运用已经有了某种分工。正如我们已经说过的，在攀援时手和脚是有不同用途的。手主要是用来摘取和拿住食物，就象比较低级的哺乳动物用前掌所作的那样。有些猿类用手在树林中筑巢，或者象黑猩猩一样在树枝间搭棚以避风雨。它们用手拿着木棒抵御敌人，或者以果实和石块向敌人投掷。它们在被捉住以后用手做出许多简单的模仿人的动作。但是，正是在这里我们看到：在甚至和人最相似的猿类的不发达的手和经过几十万年的劳动而高度完善化的人手之间，有多么巨大的差别。骨节和筋肉的数目和一般排列，在两种手中是相同的，然而即使最低级的野蛮人的手，也能做几百种为任何猿手所模仿不了的动作。没有一只猿手曾经制造过一把哪怕是最粗笨的石刀。

选择题整理

以下内容整理自：服务计算与服务生态系统_中国大学 MOOC(慕课) (icourse163.org)

单选 3 分 * 10 个，散步在各个 PPT，没有多选，重在理解，各凭本领。

服务、服务系统与面向服务的泛型