Notes of Software System Analysis and Design taught by Maolin Pan, SYSU, 2017.
Keypoints, assignments, courseware…

Textbook: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) by Craig Larman
中文版：UML和模式应用(原书第3版)

Introduction of SE & OOAD
UP Unified Process and Agile
Inception & Business Modeling
UseCase Modeling
Domain Modeling
Function-Modeling
Archtecture-Modeling
Object-Modeling
Design-Objects-with-Responsibilities

Introduction of SE & OOAD

Courseware

软件工程概述
 OOAD Introduction
(1. Object oriented analysis and design Part I - Introduction)

Key Point of Software Engineering ★

软件工程要点【必考】

Software Engineering Definition ★★★

软件工程的定义

(1) the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software. (2) the study of approaches as in (1) – IEEE Standard 610.12
软件工程：(1)将系统化、规范化、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。(2)对(1)中所述方法的研究。——IEEE[IEE93]
软件工程：是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过实践考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，这就是软件工程。

History of Software Engineering

其中涉及两个重要词汇 “software crisis”-软件危机， “Constructive Cost Model (COCOMO)”

software crisis The widespread lack of best practices for software at the time was perceived as a “software crisis”. 六十年代以来，随着计算机应用需求的驱动，系统软件和应用软件有很大的发展，如操作系统，编译系统和大型应用软件等。由于软件生产的复杂性和高成本，使大型软件的生产出现了很大的困难，即出现软件危机。软件工程正是为克服软件危机而提出的一种概念，并在实践中不断地探索它的原理，技术和方法。在此过程中，人们研究和借鉴了工程学的某些原理和方法，并形成了一门新的学科─软件工程学。

The Constructive Cost Model (COCOMO) is a procedural software cost estimation model developed by Barry W. Boehm. The model parameters are derived from fitting a regression formula using data from historical projects.结构化成本估算模型

Software Engineering Body of Knowledge

必须知道本课程涉及的KA==

Software LifeCycle

软件生命周期 从时间角度，把整个周期划分为若干个阶段。划分的原则：各阶段的任务彼此间尽可能相对独立，同一个阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂性，简化不同阶段之间的联系，有利于软件开发过程的组织管理。受软件规模、性质、种类、开发方法等因素的影响。
典型划分GB8567（4个时期7个阶段）：

软件分析时期：问题定义、可行性研究、需求分析
软件设计时期：总体设计、详细设计
编码与测试时期：编码、测试
运行与维护时期

必须了解三个过程的特点，流程
Waterfall development The waterfall model is a sequential development approach, in which development is seen as flowing steadily downwards (like a waterfall) through several phases, typically:

Requirements analysis resulting in a software requirements specification
Software design
Implementation
Testing
Integration, if there are multiple subsystems
Deployment (or Installation)
Maintenance

Iterative and incremental development Iterative development prescribes the construction of initially small but ever-larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.

Agile development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve via collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system.
There are many agile methodologies, including:

Dynamic systems development method (DSDM)
Kanban
Scrum

Software Process Improvement for Enterprise

Also see : Capability Maturity Model Integration (CMMI)要点：给企业一个明确的 5 级分类指标，推动企业在在软件工程各个 KPA 向上爬！
见第二课：2 - UP Unified Process and Agile

Also see : 软件工程国家标准其中，计算机软件产品开发文件编制指南GB／T 8567－2006最重要。否则政府项目无法验收！

Key Point of Courseware

Software Quality & Custom Experience

分析设计的目标就是生产高品质且满足客户需求的软件产品
软件质量属性划分与度量却是一个复杂话题
- 简单划分：功能需求、非功能需求
- ISO 9126-3
- ISO/IEC 25000-2014: 系统和软件工程–系统和软件质量要求和评估(SQuaRE)
- Consortium for IT Software Quality (CISQ)
Software Quality != Custom Experience
Custom Experience != 用户数量（流量）
用户数量 单用户价值 社会责任

Analysis vs. design ★

Analysis

emphasizes an investigation of the problem and requirements, rather than a solution.
分析强调对问题和需求的调查研究，而不是解决方案。
do the right thing
做正确的事（分析）

Design

emphasizes a conceptual solution (in software and hardware) that fulfills the requirements, rather than its implementation. For example, a description of a database schema and software objects.
设计强调满足需求的概念上的解决方案，而不是其实现。
do the thing right
正确地做事（设计）

Object vs. Class

Chap 1 Object-oriented Analysis and Design ★

Object-oriented analysis 面向对象分析

emphasis on finding and describing the objects—or concepts — in the problem domain. For example, in the case of the flight information system, some of the concepts include Plane, Flight, and Pilot.
强调在问题领域内发现和描述对象（或概念）

Object-oriented design

Emphasis on defining software objects and how they collaborate to fulfill the requirements. For example, a Plane software object may have a tailNumber attribute and a getFlightHistory method
强调定义软件对象以及它们如何协作以实现需求

UML (Unified Modeling Language) ★

The UML is standard diagramming language to visualize the results of analysis and design.
统一建模语言（UML）是描述、构造和文档化制品的可视化语言。
Notation (the UML) is a simple, relatively trivial thing.
Much more important: Skill in designing with objects. Learning UML notation does not help.
UML仅仅是标准的图形化表示法，不可能与设计和对象思想同等重要
The UML is not
- a process or methodology
- object-oriented analysis and design
- guidelines for design
Three Ways to Apply UML 应用UML的三种方式
Agile modeling emphasizes UML as sketch.
- UML as sketch 草图：非正式、不完整
  - Informal and incomplete diagrams (often hand sketched on whiteboards) created to explore difficult parts of the problem or solution space, exploiting the power of visual languages.
- UML as blueprint 蓝图：相对详细
  - Relatively detailed design diagrams used either for
    - reverse engineering to visualize and better understanding existing code in UML diagrams 逆向工程
    - code generation (forward engineering) 前向工程
  - If reverse engineering, a UML tool reads the source or binaries and generates (typically) UML package, class, and sequence diagrams. help the reader understand the big picture elements, structure, and collaborations.
  - Before programming, some detailed diagrams can provide guidance for code generation (e.g. Java), either manually or automatically with a tool.
- UML as programming language 编程语言：用UML完成软件系统可执行规格说明
  - Complete executable specification of a software system in UML. Executable code will be automatically generated, but is not normally seen or modified by developers; one works only in the UML “programming language.” This use of UML requires a practical way to diagram all behavior or logic (probably using interaction or state diagrams), and is still under development in terms of theory, tool robustness and usability.
Class-related terms consistent with the UML and the UP 与类相关的术语将与UML和UP保持一致
- Conceptual class — real-world concept or thing. A conceptual or essential perspective. The UP Domain Model contains conceptual classes.
  概念类：现实世界中的概念或事物。
- Software class — a class representing a specification or implementation perspective of a software component, regardless of the process or method.
  软件类：无论在过程还是在方法中，都表示软件构件在规格说明或实现透视图中的类
- Implementation class — a class implemented in a specific OO language such as Java
  实现类：特定OO语言（如Java）中的类

UP Unified Process and Agile

Courseware

Unified Process
(2. Iterative, evolutionary, and agile Part I - Introduction)

Reference:

Cai, SYSU, Software Testing: Methods & Technologies
统一软件开发过程(RUP)简介-王立福

软件团队管理基础

软件团队是软件生产的基本单元，承担30-100个人月工作量的项目。
软件过程在软件管理过程中的重要性。
现代软件过程是怎么组织的？
项目：围着特定目标进行的一次性的生产活动.
项目管理的基础：人

知识分子的管理要点与艺术

经典阅读：[美] 彼得·德鲁克《卓有成效的管理者》，豆瓣
领导者 在现代企业组织里，每个知识工作者依靠地位和知识都可能成为”管理者”，他可能会被推上负责的岗位，并能为改善机构的运作能力和获得成果作出自己的贡献。

团队的领导者：按技术特长和项目需要设置管理者，他们是平等的，仅是分工不同。常见职位：项目经理，技术经理，产品经理，测试经理，架构师，配置与质量保证经理。

时间管理 掌握自己的时间。每个知识分子应能自己记录时间、管理时间、统一安排可以自由支配的时间，使自己的工作卓有成效。团队规模越大，你需要做许多影响他人的决策，自己可掌握的时间越少，知识工作者效率越低。

团队的大小：6-8人，多数时间各人自己支配。自我组织，自我管理是现代软件团队的特点。

重视贡献 注重绩效与结果。管理者必须承偌贡献的有效性，并在一个合理端的时间内呈现成果。

团队的绩效：必须在一个短周期内呈现，以免错误决策导致最终结果。记住，项目经理是无法确定技术经理决定对错的，必须在一个开发周期结束评估结果和贡献，带领团队和个人持续改进。必须是可度量的。包括：工作量、创新性（技术、管理）、时效性、质量

发挥所长 充分发挥各自优势就是机构存在的唯一目的。

团队的构成：必须是一群能力互补的团队，不是一堆能干活（编程）的。

要事优先 善于集中精力。卓有成效的管理者总是把重要的事情放在前面先做（first things first），一次做好一桩事情（do onething at a time）。

软件团队：了解软件开发包含哪些阶段，必须要达成的目标，最重要的工作是什么，常见的风险、问题与缺陷是什么！

需求分析设计：就是教你如何发现要是，并做好关键任务的教程！！！

目标管理

先有目标才能确定工作，所以“企业的使命和任务，必须转化为目标”。

软件团队组织模型

开发团队人员比例：1:1:1 = 项目（客户）经理：技术：测试
围绕高品质产品，各施其职：

客户喜欢（用户体验好），乐于使用并产生价值（带来更多经济或社会或个人价值）。
技术优雅，可持续支持软件的发展与进化。
产品定位清晰，资料完善，无明显使用缺陷。

软件开发过程模型

过程（资产）建设在软件企业中的重要性
ISO-9000，CMMI 认证
瀑布模型、增量模型、螺旋模型的优缺点
风险（需求），规模（工作量），工期的控制分析

CMMI五个级别

初始级：无序，自发生产模式。
可管理级：项目管理，过程纪律
已定义级：标准化
量化管理级：量化，可控
优化管理级：持续改进

Level 1 – Initial: unpredictable, reactive
Level 2 – Managed: characterized, reactive
Level 3 – Defined: characterized, proactive
Level 4 – Quantitatively Managed: measured, controlled
Level 5 – Optimizing: process improvement

Waterfall Model 瀑布模型 ★

Idea->Analysis->Design->Development->Test->Final Product

假设： 需求是明确的，在短期内可获取每个阶段是无差错的
优势：定义了软件开发基本流程与活动
劣势：
- 依赖问题：前面需求模糊，后面工作…
- 容错问题：在后期发现需求问题，工作量难接受
- 资源调配问题：知识技能需求不同、人员数量要求不同
现象：延期，项目不可控

增量模型

假设：需求明确
解决问题：项目控制、团队组织

原型与螺旋模型

假设：需求随用户评估进化
新问题：迭代次数？不适合大团队。无法确定发布日期

—> 迭代、敏捷开发

Chap 2 Iterative, Evolutionary, and Agile

迭代、敏捷开发是OOAD的关键“最佳实践”

Unified Process ★ 统一过程

The Unified Process (UP) represents a mainstream approach for software development across the spectrum of project scales.
The process is scalable: you need not use the entire framework of the process for every project, only those that are effective.
The process is effective: it has been successfully employed on a large population of projects.
Improves productivity through use of practical methods that you’ve probably used already (but didn’t know it).
Iterative and incremental approach allows start of work with incomplete, imperfect knowledge.

Unified Process Workflows ★★

Workflows define a set of activities that are performed
Workflows cut across the phases, but with different levels of emphasis in each phase
The core workflows
- Business Modeling.业务模型
- Requirements Analysis
- Design
- Implementation
- Test and Integration

Use-Case-Driven ★★

Use case
- A prose representation of a sequence of actions
- Actions are performed by one or more actors (human or nonhuman)
  and the system itself
- These actions lead to valuable results for one or more of the actors—helping the actors to achieve their goals
Use cases are expressed from the perspective of the users, in natural language, and should be understandable by all stakeholders
Use-case-driven means the development team employs the use cases from requirements gathering through code and test.

Architecture Centric ★★

Architecture-centric: software architecture provides the central point around which all other development evolves. Software architecture captures decisions about:

Software architecture captures decisions about:

The overall structure of the software system
The structural elements of the system and their interfaces
The collaborations among these structural elements and their expected behavior

Iterative and Evolutionary ★★

An iterative and evolutionary approach allows start of development with incomplete, imperfect knowledge
Iterative and evolutionary the following advantages
- Logical progress toward a robust architecture（逐步趋向稳定）
- Effective management of changing requirements（有效管理需求变化）
- Continuous integration（持续集成）
- Early understanding of the system (‘Hello world!’ effect)（尽早接触整个系统）
- Ongoing risk assessment（在线风险评估）

Iterations are fixed in length, or timeboxed.（固定周期）量化管理的需求

Agile Methods and Attitudes ★

The Agile Manifesto 敏捷宣言
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Agile Principles
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development
- …

Agile Modeling ★

Adopting an agile method does not mean avoiding any modeling
The purpose of modeling and models is primarily to support understanding and communication, not documentation.
Don’t model or apply the UML to all or most of the software design.
Know that all models will be inaccurate, and the final code or design different sometimes dramatically different than the model.
…

Unified Process Phases ★

Artifacts, Workers, and Activities ★

An artifact is a piece of information that is used as input to, changed by, or output from a process
Examples include:
- Models — use-case, domain, and design
- Model elements—use case, domain class, design class
- Diagrams and documents
- Source code
- Executable elements
Some important distinctions:
- Workers participate in the development of the system
- Actors are outside the system and have usage relationships with the system
- Stakeholders encompass both actors and workers, as well as others involved with the project

Assignment

CMU与美国国防部合作提出CMM/CMMI模型，解决了美国国防部什么问题？它对软件产业的作用是什么？

(1) CMM/CMMI解决了美国政府和美国国防部能有效地评估软件承包商的问题。
CMM（CMMI是SEI于2000年发布的CMM的新版本）是“软件能力成熟度模型”的英文简写，该模型由美国卡内基-梅隆大学的软件工程研究所（简称SEI）受美国国防部委托，于1991年研究制定，初始的主要目的是为了评价美国国防部的软件合同承包组织的能力，后因为在软件企业应用CMM模型实施过程改进取得较大的成功，所以在全世界范围内被广泛使用。

(2) 它对软件企业的作用是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架。因而能够从总体上改进组织的质量和效率。CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。
（参考自百度百科CMMI/CMI词条）

简述瀑布模型、增量模型、螺旋模型（含原型方法）的优缺点。

瀑布模型

优点：定义了软件开发基本流程与活动
缺点：
- 依赖问题：前面需求模糊，后面工作…
- 容错问题：在后期发现需求问题，工作量难接受
- 资源调配问题：知识技能需求不同、人员数量要求不同

增量模型

优点：
- 由于能够在较短的时间内向用户提交一些有用的工作产品，因此能够解决用户的一些急用功能
- 由于每次只提交用户部分功能，用户有较充分的时间学习和适应新的产品
- 对系统的可维护性是一个极大的提高，因为整个系统是由一个个构件集成在一起的，当需求变更时只变更部分部件，而不必影响整个系统
缺点：
- 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构
- 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性
- 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程

原型与螺旋模型

优点：
- 设计上的灵活性,可以在项目的各个阶段进行变更
- 以小的分段来构建大型系统,使成本计算变得简单容易
- 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性
- 随着项目推进,客户始终掌握项目的最新信息, 而他或她能够和管理层有效地交互
- 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品
缺点：
- 迭代次数不确定
- 不适合大团队
- 无法确定发布日期
- 很难让用户确信这种演化方法的结果是可以控制的
- 建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求

简述RUP的三大特点，其中哪些内容体现了用户驱动的开发，哪些内容体现风险驱动的开发？

RUP的三大特点是以用户为驱动的、以体系结构为中心的、迭代、增量式开发。第一个特点的内容体现了用户驱动的开发。第二个特点的内容体现风险驱动的开发。具体内容见下文。

以用户为驱动

意指在系统的生存周期中，以用户作为基础，驱动有关人员对所要建立系统之功能需求进行交流，驱动系统分析、设计、实现和测试等活动，包括制定计划、分配任务、监控执行和进行测试等，并将它们有机地组合为一体，使各个阶段中都可以回溯到用户的实际需求。

以体系结构为中心

意指在系统的生存周期中，开发的任何阶段（RUP规定了四个阶段，即初始阶段、细化阶段、构造阶段和移交阶段）都要给出相关模型视角下的有关体系结构的描述，作为构思、构造、管理和改善系统的主要制品。

迭代、增量式开发

意指通过开发活动的迭代，不断地产生相应的增量。在RUP中，规定了四个开发阶段：初始阶段（the inception phase）、精化阶段（ the elaboration phase）、构造阶段（ the constructionphase）和移交阶段（ the transition phase）。每次迭代都要按照专门的计划和评估标准，通过一组明确的活动，产生一个内部的或外部的发布版本。两次相邻迭代所得到的发布版本之差，称为一个增量，因此增量是系统中一个较小的、可管理的部分(一个或几个构造块)。贯穿整个生存周期的迭代，形成了项目开发的一些里程碑。

RUP通过迭代增量建模思想提高了风险控制能力，这体现在：

迭代计划安排是风险驱动的，高风险因素集中在前两个阶段解决，特别是体系结构级的风险在细化阶段就得到了解决，及早降低了系统风险；
每一次迭代都包括需求、设计、实施、部署和测试活动，因此，每一个中间产品都得到了集成测试，而且这个集成测试是在一个统一的软件体系结构指导下完成的；
每一个阶段结束时严格的质量评审，保证里程碑文档的质量；
由于中间版本的产品是逐步产生的，而且核心功能和性能需求已经包含在前面的版本中，所以，可以根据市场竞争的情况适时推出中间版本，降低市场风险。

迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解从而降低了项目的风险。RUP的要点之一是在项目早期就标识并处理最大的风险。项目组标识的每一个风险都应该有一个相应的缓解或解决计划。风险列表应该既作为项目活动的计划工具，又作为确定迭代的基础。

RUP四个阶段的划分准则是什么？关键的里程碑是什么？

RUP阶段	划分准则	里程碑
初始阶段	建立该项目的生存周期目标。系统建立业务案例(business case) 并确定项目的边界。	生命周期目标（Lifecycle Objective）里程碑。包括一些重要的文档，如：项目构想(vision)、原始用例模型、原始业务风险评估、一个或者多个原型、原始业务案例等。需要对这些文档进行评审，以确定正确理解用例需求、项目风险评估合理、阶段计划可行等。
细化阶段	建立系统的体系结构基线。析问题领域，建立健全的体系结构基础，编制项目计划，完成项目中高风险需求部分的开发。	生命周期结构（Lifecycle Architecture）里程碑。包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。通过评审确定软件体系结构已经稳定、高风险的业务需求和技术机制已经解决、修订的项目计划可行等。
构造阶段	形成一个可基本交付使用的产品/系统。成所有剩余的技术构件和稳定业务需求功能的开发，并集成为产品，所有功能被详细测试。	初始运行能力（Initial Operational Capability）里程碑。包括可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运行。
交付阶段	向用户交付一个可使用的产品/系统。产品化阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。	产品发布（Product Release）里程碑。此时，要确定最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的相重合。

IT项目管理中，“工期、质量、范围/内容”三个元素中，在合同固定条件下，哪个最容易与客户达成妥协？理由？

质量最容易妥协。参见IT项目合同变更的范围和内容：

增加或减少合同中任何一项工作内容
取消合同中任何一项工作
改变合同中任何一项工作的标准或性质
改变IT项目设计报告
改变合同中任何一项IT项目的完工时间或改变已批准的顺序
追加为完成IT项目所需的任何额外工作。额外工作指合同中为了完成合同IT项目所需增加的新项目。

第五点明确指出工期属于合同变更范围，难以妥协。第1、2、4、6点均是属于范围/内容变更，难以妥协。而质量元素可以参考第三点：标准或性质，最容易与客户达成妥协。
工期是指约定完成IT项目工程的时间。项目范围的概念包含了两个方面的内容，一个是产品范围，即产品或服务所包含的特征或功能，另一个是项目范围，即为交付具有规定特征和功能的产品或服务所必须完成的工作。
软件质量的定义是：与软件产品满足规定的和隐含的需要的能力有关的特征或特性的组合。软件质量的要素有正确性，健壮性，效率，完整性，可用性，风险性。从用户角度对质量的认识是：有效性，效率，灵活性，完整性，互操作性，可靠性，健壮性，可用性。从开发者角度对质量的认识是：可维护性，可重用性，可测试性。可以看出，质量是难以量化和确切衡量的，合同中对质量的约束也是较为宽泛的。因此在合同固定的情况下也可以和客户进行商榷和达成妥协。

RUP为企业按固定节奏生产、固定周期发布软件产品提供了依据，为什么？

依据：RUP中，软件开发生命周期根据时间（固定周期发布）和RUP的核心工作流（固定节奏生产）划分为二维空间。时间维从组织管理的角度描述整个软件开发生命周期，是RUP的动态组成部分。它可进一步描述为周期(Cycle)、阶段(Phase)、迭代(Iteration)。核心工作流从技术角度描述RUP的静态组成部分，它可进一步描述为行为(Activities)、工作流(Workflow)、产品(Artifact)、角色(Worker)。

（可集体讨论）讲述软件开发中 1-2个有效的敏捷实践，以及依据。

参考《敏捷实践的秘密II》，大型软件组织通常都很重视产品质量，并在开发/测试阶段投入大量成本与精力进行质量保障活动。但软件产品的质量问题不仅在开发阶段引入，靠传统意义上的测试工作也不能完全发现。有相当比例的质量问题是在开发/测试阶段之后引入或发现的。通过引入自动化测试、测试驱动开发、持续集成等敏捷实践，开发/测试阶段的质量保障活动能够得到有效改善。具体内容和依据如下：

迭代式开发 已经习惯于固定的短周期迭代的开发团队能够更好地融入快速交付的整体节奏。
自动化测试 有效的自动化测试套件能在软件生命周期的各个环节保障系统质量，避免引入缺陷。
持续集成 拥有成熟的项目自动化机制和能力，开发团队能帮助运营团队更快地建立发布与维护过程的自动化体系，从而实现软件价值的持续交付。

通过敏捷实践，软件组织能够明显软件产品发布和运营过程中的质量与效率。具体而言，可感知的收益包括：

缩短交付周期，新需求能更快投入使用并创造业务价值。
增加软件发布的可靠性，减少上线后的质量事故。
减少发布和运营中的浪费，提高运营团队的工作效率。
可视化度量软件交付过程，以便快速识别问题、持续改善。
在开发与运营团队之间建立更加高效的协作关系。

更多内容可参考《敏捷实践实施模式技术实践组合》中的敏捷实施策略章节

（可集体讨论）选择一个可追溯到初始版本的软件，如“知乎”，你认为实现当初类似“stack-overflow”这类问答模式的软件，需要多少人，多少月？

在ArchSummit北京2014大会上，知乎联合创始人兼CTO李申申带来了知乎创业三年多来的首次全面技术分享（演讲内容整理）：知乎在2010年10月真正开始动手做知乎这个产品时，包含李申申在内，最初只有两位工程师；到2010年12月上线时，工程师是四个。最初整个团队的精力全部放在产品功能的开发上，而其他方面，基本上能节约时间、能省的都用最简单的方法来解决，当然这在后期也带来了一些问题。在2011年上半年时，单机存储成为瓶颈，所以引入了分片，同时做了一致性。知乎最初是邀请制的，2011年下半年，知乎上线了申请注册，没有邀请码的用户也可以通过填写一些资料申请注册知乎。
知乎在2013年时每天有上百万的PV，页面渲染其实是计算密集型的，另外因为要获取数据，所以也有IO密集型的特点。这时开发团队就对页面进行了组件化，还升级了数据获取机制，知乎自己做了一套模板渲染开发框架——ZhihuNode。在2014年时，知乎在规模上是仅次于百度贴吧和豆瓣的中文互联网最大的UGC(用户生成内容)社区。
参考知乎的发展时间线，他们在2010年时从两人到四人历时约三个月上线了最初的产品，已经具有类似stack overflow的问答模式。现在2017年，技术在发展、自动化工具更加普遍易于使用、架构更加完善、可参考的发展模式更多、开发流程更加多样和完善，因此我认为时间人力不比当年多，实现当初类似“stack-overflow”这类问答模式的软件，需要四个人，三个月。

Inception & Business Modeling

Courseware

Inception
(Chap 4,5 - Part II Inception)

Chap 4 Inception is Not the Requirements Phase

Inception Phase ★★

Inception phase: envision the product scope, vision, and business case.
初始阶段是建立项目共同设想和基本范围的比较简短的起始步骤。初始阶段的目标不是定义所有需求，或产生可信的预算或项目计划
- Buy and/or build this system?
- Rough unreliable range of cost ?
- Should we proceed or stop?
- Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation?
Most requirements analysis during the elaboration phase, in parallel with early production-quality programming and testing
大多数需求分析是在细化阶段进行的，并且伴以具有产品品质的早期编程和测试
Inception phase should be relatively short for most projects. (one or a few weeks long)
初始阶段持续时间短

Chap 5 Evolutionary Requirements

Requirement are a description of need or desired for a product. ★
- Goal - to identify and document what is really needed, in a form that clearly communicates to the client and to development team members.
  寻找、沟通和记录什么是真正需要的，并能够清楚地讲解给客户和开发团队的成员
- Challenge - to define the requirement unambiguously.
In UP, requirements are categorized according to the FURPS+ model. ★★
在统一过程中，需求按照“FURPS+”模型进行分类
- Functional: features, capability, security
  功能性：特性、功能、安全性
- Usability: human factors, help, documentation
  可用性：人性化因素、帮助、文档
- Reliability: frequency of failure, recoverability, predictability
  可靠性：故障频率、可恢复性、可预测性
- Performance: response times, throughput, accuracy, availability, resource usage.
  性能：响应时间、吞吐量、准确性、有效性、资源利用率
- Supportability: adaptability, maintainability, internationalization, configurability
  可支持性：适应性、可维护性、国际化、可配置性

UseCase Modeling

Courseware

UseCase Model
(Chap 6 Use Cases - Part II Inception)
微软项目建模实践
 建模练习

Chap 6 Use Cases

Actors(参与者) ★★

Actor: external entity interacts (behavior) with system 参与者是具有某些行为的事物
- Primary actor has user goals fulfilled through using services. Find user goals to drive the use cases.
  主要参与者：具有用户目标，并通过使用SuD服务完成。例如，收银员用于发现驱动用例的用户目标
- Supporting actor provides a service. Often a computer system, but could be an organization or person. The purpose is to clarify external interfaces and protocols.
  协助参与者：为SuD提供服务（如信息服务）。自动付费授权服务即是一例。协助参与者通常是计算机系统，也可以是组织或人。用于明确外部接口和协议
- Offstage actor has an interest in the behavior of the use case, but is not primary or supporting.
  幕后参与者：在用例行为中具有影响或利益，但不是主要或协助参与者。例如，政府税收机构。用于确保确定并满足所有必要的重要事务。如果不明确地对幕后参与者进行命名，则有时很容易忽略其影响或利益

Use Case(用例) ★

Use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal.
用例是一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标
be text documents, not diagrams
用例是文本文档，而非图形
Use case modeling is primarily an act of writing text, not drawing diagrams.
用力建模主要是编写文本的活动，而非制图
There is nothing object-oriented about use cases;
用例不是面向对象的，编写用例时也不会进行OO分析。但这并不妨碍其有效性，用例可以被广泛应用。也就是说，
Use cases are a key requirements input to classic OOA/D.
用例是经典OOA/D的关键需求输入
be functional or behavioral requirements that indicate what the system will do. In terms of the FURPS+ requirements types, they emphasize the “F”, but can also be used for other types.
用例就是需求，主要是说明系统如何工作的功能性或行为需求。按照“FURPS+”需求类型，用例强调了“F”（功能性或行为性），但也可以用于其他类型，特别是与用例紧密相关的那些类型。

Use Case Modeling(用例模型) ★

Be the set of all written use cases; it is a model of the black-box system’s functionality and environment.
所有书面用例的集合；系统功能性和环境的模型
be not the only requirement artifact in the UP. There are also the Supplementary Specification, Glossary, Vision, and Business Rules.
在UP中不是唯一的需求制品。其他制品还有补充性规格说明、词汇表、设想和业务规则
Use case modeling is primarily an act of writing text, not drawing diagrams.
主要是编写文本的活动，而非制图
may optionally include a UML use case diagram to show the names of use cases and actors, and their relationships. This gives a nice context diagram of a system and its environment.
用例模型还可以包含UML用例图，以显示用例和参与者的名称及其关系。UML用例图可以为系统及其环境提供良好的语境图

Three Common Use Case Formats ★

Brief (high level) 摘要
- Terse one-paragraph summary, usually of the main success scenario.
  简洁的一段式概要，通常用于主成功场景
- During early requirements analysis, to get a quick sense of subject and scope. May take only a few minutes to create.
  在早期需求分析快速了解主题和范围
Casual 非正式/简便格式
- Informal paragraph format.
  非正式的段落格式。用几个段落覆盖不同场景
Fully 详述
- All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees.
  详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。
- After many use cases have been identified and written in a brief format, then during the first requirements workshop a few (such as 10%) of the architecturally significant and high-value use cases are written in detail.
  确定并以摘要形式编写了大量用例后，在第一次需求讨论会中，详细地编写其中少量（例如10%）的具有重要架构意义和高价值的用例

Fully Use Case Template
中文书：P55-59

Guideline: How to Write Use Cases ★

Write in an Essential UI-Free Style. During early requirements work, “keep the user interface out, focus on intent.”
以本质风格编写用例，摒除用户界面并且关注参与者的意图
Write Terse Use Cases. Delete “noise” words
编写简洁的用例，删除“噪音”词汇
Write Black-Box Use Cases. do not describe the internal workings of the system, its components, or design.
写黑盒用例：不对系统内部工作、构件或设计进行描述
Take an Actor and Actor-Goal Perspective
采用参与者和参与者目标的视点

Guideline: How to Find Use Cases ★★★

Use cases are defined to satisfy the goals of the primary actors. The basic procedure is:
为满足主要参与者的目标而定义用例。因此，基本的过程如下：

Choose the system boundary.
选择系统边界
Identify the primary actors – that have goals fulfilled through using services of the system.
确定主要参与者——通过使用系统地服务实现其目标的那些人或事物
Identify the goals for each primary actor.
确定每个主要参与者的目标
Define use cases that satisfy user goals; name them according to their goal.
user-goal level use cases will be one-to-one with user goals.
定义满足用户目标的用例，根据其目标对用例命名。通常，用户目标级别的用例和用户目标是一一对应的。

应用UML：用例图

用例图是一种优秀的系统语境图；也就是说，用例图能够展示系统边界、位于边界之外的事物以及系统如何被使用。用例图可以作为沟通的工具，用以概括系统及其参与者的行为。

应用UML：活动图 ★★★

有助于使工作流和业务过程可视化的图

应用UML：状态图

Domain Modeling

Courseware

Domain Model
(Part III Elaboration Iteration I – Basic)

Introduction ★

A domain model（领域模型）
- the most important and classic model in OO analysis.
  OO分析中最重要和经典的模型
- be a visual representation of conceptual classes or real situation objects in a domain.
  对领域内的概念类或现实世界中对象的可视化表示（而非软件对象的表示）
- Also called conceptual models, domain object models, and analysis object models.
  也称为概念模型、领域对象模型和分析对象模型
- “focusing on explaining ‘things’ and products important to a business domain”
  “专用于解释业务领域中重要的‘事物’和产品”
Guideline（准则）
- Avoid a waterfall-mindset big-modeling effort to make a thorough or “correct” domain model
  避免瀑布思维倾向，为完成详尽或“正确”的领域模型而进行大量建模工作。
- it won’t ever be either, and such over-modeling efforts lead to analysis paralysis, with little or no return on the investment.
  过量的建模工作反而会导致分析停滞，这种调查几乎不会有什么回报

Domain Model

It provides a conceptual perspective. ★★ 它提供了概念透视图
- domain objects or conceptual classes 领域对象或概念类
- associations between conceptual classes 概念类之间的关联
- attributes of conceptual classes 概念类的属性
Following elements are not suitable in a domain model ★★
- Software artifacts, such as a window or a database, unless the domain being modeled is of software concepts, such as a model of graphical user interfaces.
  软件制品，例如窗口或数据库，除非已建模的领域模型是针对软件概念的，如图形化用户界面的模型
- Responsibilities or methods. 指责或方法
A domain model shows real-situation conceptual classes, not software classes ★
领域模型表示真实世界概念类，不是软件类
A domain model does not show software artifacts or classes ★
领域模型并非软件制品或类
A conceptual class is an idea, thing, or object. ★ 概念类是思想、事物或对象
- Symbol words or images representing a conceptual class
  符号：表示概念类的词语或图形
- Intension the definition of a conceptual class.
  内涵：概念类的定义
- Extension the set of examples to which the conceptual class applies
  外延：概念类所使用的一组示例

Guideline

Create a Domain Model

Bounded by the current iteration requirements under design ★★★ 以当前迭代中所要设计的需求为界
- Find the conceptual classes. 寻找概念类
- Draw them as classes in a UML class diagram. 将其绘制为UML类图中的类
- Add the association necessary to record relationships for which there is a need to preserve some memory. 添加关联
- Add the attributes necessary to fulfill the information requirements. 添加属性

Find Conceptual Classes ★★

找到概念类的三条策略

Reuse or modify existing models. 重用和修改现有的模型
Use a category list. 使用分类列表
Identify noun phrases from the case text 通过识别名词短语寻找概念类
- Identify the nouns and noun phrases in textual descriptions of a domain, and consider them as candidate conceptual classes or attributes
  在对领域的文本性描述中识别名词和名词短语，将其作为候选的概念类或属性
- Some of these noun phrases may refer to conceptual classes that are ignored in this iteration, and some may be simply attributes of conceptual classes.
  有些名词所指的概念类可能会在本次迭代中忽略，还有一些可能只是概念类的属性
- A weakness of this approach is the imprecision of natural language; different noun phrases may represent the same conceptual class or attribute, among other ambiguities.
  弱点：自然语言的不准确性。不同名词短语可能表示同一概念类或属性，此外可能还有歧义

Report Objects Include ‘Receipt’ in the Model ★★

报表对象——模型中是否要包含“票据”

Receipt is a noteworthy term in the POS domain. But perhaps it’s only a report of a sale and payment, and duplicate information. Two factors to consider
- Exclude it: Showing a report of other information in a domain model is not useful since all its information is derived or duplicated from other sources.
  排除：在领域模型中显示其他信息的报表没有意义，因为其所有信息都是源于或复制于其他信息源的
- Include it: it has a special role in terms of the business rules: It confers the right to the bearer of the receipt to return bought items.
  包含：就业务规则而言，它有特殊的作用：通常持有（纸质）票据的人有退货的权利
Since item returns are not being considered in this iteration, Receipt will be excluded.
因为在本次迭代中没有考虑退货，所以不应该包含票据。在解决处理退货用例的迭代中再考虑将其包含在内

A Common Mistake with Attributes vs. Classes ★★

If we do not think of some conceptual class X as a number or text in the real world, X is probably a conceptual class, not an attribute.
如果我们认为某概念类X不是现实世界中的数字或文本，那么X可能是概念类而不是属性

In the real world, a store is not considered a number or text, the term suggests a legal entity, an organization, and something that occupies space. Therefore, Store should be a conceptual class.
在现实世界里，商店不会被认为是数字或文本，这一术语表示的是合法实体、组织和占据空间的事物。因此Store应该是概念类。

When to Model with ‘Description’ Classes ★★

何时使用“描述”类建模
A description class contains information that describes something else.
描述类包含描述其他事物的信息。

需要有关商品或服务的描述，独立于任何商品或服务的现有实例
删除其所描述事物的实例后，导致信息丢失，而这些信息是需要维护的，但是被错误地与所删除的事物联系起来
减少冗余或重复信息

例如，ProductDescription记录Item的价格、图片和文字描述

Problems: if implemented in software similar to the domain model, it has duplicate data (space-inefficient, and error-prone).
如果软件实现模型类似于领域模型，则其中含有重复数据，这会降低空间利用效率并有可能产生错误，因为描述、价格和ID对于同一产品的每个Item实例来说都是重复的
A particular Item may have a serial number; it represents a physical instance. A ProductDescription wouldn’t have a serial number
某个Item可能拥有序列号，用于表示其物理实例。ProductDescription则没有序列号

对象需要其他事物来记录其描述（规格说明）。为解决Item问题，需要ProductDescription类来记录商品的信息。ProductDescription并不代表Item，而是表示有关商品的描述信息。

Association ★

a relationship between classes (instances of those classes) that indicates some meaningful and interesting connection.
关联是类的实例之间的关系，表示有意义和值得关注的连接
关联本质上是双向的，就是说无论从哪个类实例出发，到另一端的逻辑遍历都是可能的。这种遍历是春抽象的，与软件实体间的连接无关。可选的“阅读导向箭头”指示阅读关联名称的方向；但它并不表示可见性或导航的方向
应使用关联而不是属性将类型关联起来

Guideline

When to Show an Association: Associations imply knowledge of a relationship that needs to be preserved for some duration.
关联表示了需要持续一段时间的关系
Avoid Adding Many Associations: Many lines on the diagram will obscure it with “visual noise.”
避免加入大量关联：连线太多会产生“视觉干扰”，使图变得混乱
Name an association: based on a ClassName-VerbPhraseClassName format where the verb phrase creates a sequence that is readable and meaningful.
以“类名-动词短语-类名”的格式为关联命名，其中的动词短语构成了可读的和有意义的顺序
- Association names should start with a capital letter, since an association represents a classifier of links between instances;
  关联名称应该首字母大写，因为关联表示的是实例之间链接的类元。在UML中，类元应该首字母大写
- 反例：Sale Paid-by CashPayment（没有增加意义），应改为Sale Uses CashPayment
- 反例：Player Is-on Square（没有增加意义），应改为Player Has Square

Perspectives: Will the Associations Be Implemented In Software?

观点：关联是否会在软件中实现
During domain modeling, an association is not data flows, database foreign key relationships, instance variables, or object connections in software solution. It is meaningful in a purely conceptual perspective in the real domain.
在领域建模过程中，关联不是关于数据流、数据库外键联系、实例变量或软件方案中的对象链接的语句；关联声明的是针对现实领域从纯概念角度看有意义的关系。

也就是说，这些关系的大部分将作为（设计模型和数据模型中的）导航和可见性路径在软件中加以实现。但是领域模型不是数据模型；添加关联是为了突出我们对重要关系的大致理解，而非记录对象或数据的结构。

Applying UML: Roles

Each end of an association is called a role. Roles may optionally have multiplicity expression, name, navigability.
关联的每一端称为角色。角色可具有多重性表达式、名称、导航。

Attributes

An attribute is a logical data value of an object 属性是对象的逻辑数据值
没有属性的概念类是合法的。大部分属性应该是“简单”数据类型，例如数字和布尔。

Guideline: When to Show Attributes?

Include attributes that the requirements (e.g., use cases) suggest or imply a need to remember information.
当需求（例如，用例）建议或暗示需要记住信息时，引入属性
e.g., a receipt (which reports the information of a sale) in the Process Sale use case normally includes a date and time, the store name and address, and the cashier ID
例如，在处理销售用例中的票据通常含有日期和时间、店名和地址以及收银员ID等

POS Partial Domain Model ★★★

Assignment

领域建模学习小结

简述领域模型在项目开发中的作用
参考领域驱动设计和开发实战，领域模型在项目开发中的作用有
- 有助于团队创建一个业务部门与IT部门都能理解的通用模型，并用该模型来沟通业务需求、数据实体、过程模型。
- 模型是模块化、可扩展、易于维护的，同时设计还反映了业务模型。
- 提高了业务领域对象的可重用性和可测性。
简述数据库模型与领域模型的差异

领域模型可以被看作是一个系统的概念模型，用于以可视化的形式描述系统中的各个实体及其之间的关系。领域模型记录了一个系统中的关键概念和词汇表，显示出了系统中的主要实体之间的关系，并确定了它们的重要的方法和属性。因此，对应于用例所描述的动态视图，领域模型提供了一种对整个系统的结构化的视图。领域模型的一个好处是描述并限制了系统边界。（wiki）

模型是一种描述客观现实的抽象技术。数据模型(data model)是描述数据如何表示、如何访问的抽象模型，常用来定义特定领域的数据元素和数据元素之间的关系。在程序设计语言中，数据模型也常常称为数据结构。在数据库领域中建立的数据模型称为数据库模型。数据库模型(database model)是描述数据库结构和使用的方法和技术。（数据库模型和数据库建模）

差异：领域模型是系统的结构化视图，而数据库模型是专指数据库的结构化视图。领域模型主要描述系统中各实体的关系，而数据库模型主要描述数据的表示、关系。
假设你主导软件数据设计评审，你认为需要哪些准备文档，会关注哪些要素
参考数据库设计评审：
- 数据库设计是否满足软件设计的一般要求？数据库设计是否与其他设计内容一致？
- 设计是否充分考虑了新系统与现有系统的关系，与现有系统的接口是否被充分考虑？在数据库设计中应该充分考虑新系统与现有系统的关系，与现有系统的接口应被充分考虑。
- 反规范化（违反 3NF）的设计是否有明确的说明，理由是否充分？反规范化的设计有时是必要的，但是要注明理由。通常的理由包括：1、为了提高查询效率，在频繁查询但不频繁更新的表中增加冗余列；2、为了提高查询效率，将大容量表作水平分割（分割行）或垂直分割（分割列）；3、为了方便进行统计，引入派生列；如无恰当理由，所有设计均应遵循 3NF。
- 外部输入或导入的日期应使用 varchar 型或 char字段。典型的问题是：如果有的日期精确到日，有的日期只精确到年，那么这些数据在日期型字段中得不到准确的记录。
- 如果有移植的需求，那么是否对移植性作了充分的考虑？如果有移植需求，那么应该慎重使用函数、过程、触发器，并且要有单独的移植方案。

Function Modeling

Courseware

Elaboration - Function Modeling (Chap 10&11, Part III Elaboration Iteration I – Basic)

Chap 10 System Sequence Diagrams

系统顺序图

POS SSD: a Process Sale Scenario ★★★

System Sequence Diagram ★

系统顺序图（SSD）是为阐述与所讨论系统相关的输入和输出事件而快速、简单地创建的制品。它们是操作契约和（最重要的）对象设计的输入

System sequence diagram
- a picture that shows, for one particular scenario of a use case, the events that external actors generate, their order, and intersystem events.
  系统顺序图表示的是，对于用例的一个特定场景，外部参与者产生的事件，其顺序和系统之内的事件
- All systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems.
  所有系统被视为黑盒，该图强调的是从参与者到系统的跨越系统边界的事件
- During interaction between system and actor, an actor generates system events to a system, usually requesting some system operation to handle the event.
  在交互中，参与者对系统发起系统事件，通常需要某些系统操作对这些事件加以处理。
- UML includes sequence diagrams as a notation that can illustrate actor interactions and the operations initiated by them.
  UML包含了顺序图作为表示法，以便能够阐述参与者的交互及参与者引发的操作
Guideline: Draw an SSD for a main success scenario of each use case, and frequent or complex alternative scenarios
准则：应为每个用例的主成功场景，以及频繁发生的或者复杂的替代场景绘制SSD
SSDs are derived from use cases; they show one scenario.
SSD展示了用例中一个场景的系统事件，因此它是从对用例的考察中产生的

Chap 11 Operation Contracts

操作契约

Sections of a Contract ★★

下面对契约中的每个部分进行了描述：

Operation: Name of operation, and parameters
操作：操作的名称和参数
Cross References: Use cases this operation can occur within
交叉引用：会发生此操作的用例
Preconditions: Noteworthy assumptions about the state of the system or objects in the Domain Model before execution of the operation.
前置条件：执行操作之前，对系统或领域模型对象状态的重要假设。
Postconditions: The state of objects in the Domain Model after completion of the operation
后置条件：最重要的部分。完成操作后，领域模型对象的状态

Postconditions ★★★

Postconditions 后置条件
- describe changes in the state of objects in the domain model.
  描述了领域模型内对象状态的变化
- Domain model state changes include instances created, associations formed or broken, and attributes changed.
  领域模型状态变化包括创建实例、形成或消除关联以及改变属性
- Postconditions are not actions to be performed.
  后置条件不是在操作过程中执行的活动，相反，它们是对领域模型对象的观察结果，当操作完成后，这些结果为真，就像浓烟散去后所能够清晰看到的事物
Postconditions fall into these categories:
- Instance creation and deletion. 创建或删除实例
- Attribute change of value. 属性值的变化
- Associations (UML links) formed and broken. 形成或消除关联（UML链接）
Postconditions Related to the Domain Model
后置条件如何与领域模型相关
What instances can be created; What associations can be formed in the Domain Model.
这些后置条件主要是在领域模型对象的语境中表示的。可以创建什么实例？可以形成什么关联？等等
Motivation: Why Postconditions?
Postconditions support fine-grained detail and precision in declaring what the outcome of the operation must be
后置条件支持细粒度的细节和精确性，以声明操作必须具备的结果

Example: enterItem Postconditions ★

中文书P137-138
Postconditions of the enterItem system operation.

Instance Creation and Deletion
- After the itemID and quantity of an item have been entered, what new object should have been created? A SalesLineItem. Thus:
- A SalesLineItem instance sli was created (instance creation).
Attribute Modification
- After the itemID and quantity of an item have been entered by the cashier, what attributes of new or existing objects should have been modified? The quantity of the SalesLineItem should have become equal to the quantity parameter. Thus:
- sli.quantity became quantity (attribute modification).
Associations Formed and Broken
- After the itemID and quantity of an item have been entered by the cashier, what associations between new or existing objects should have been formed or broken?
- The new SalesLineItem should have been related to its Sale, and related to its ProductDescription. Thus:
- sli was associated with the current Sale (association formed).
- sli was associated with a ProductDescription, based on itemID match (association formed).

Archtecture Modeling

Courseware

Elaboration - Archtecture Modelling - Logical Modeling (Chap 12 & 13, Part III Elaboration Iteration I – Basic)

Chap 12 Requirements to Design Iteratively

系统顺序图

Iteratively Do the Right Thing, Do the Thing Right ★

以迭代方式做正确的事，正确地做事

Object-oriented requirements analysis
focused on to do the right thing; understanding some of the outstanding goals, and related rules and constraints.
需求和面向对象分析重点关注学习做正确的事。也就是说，要理解案例研究中的一些重要目标，以及相关的规则和约束
The following design work stress to do the thing right
skillfully designing a solution to satisfy the requirements for this iteration.
后续的设计工作将强调正确地做事。也就是说，熟练地设计解决方案来满足本次迭代的要求
In iterative development, a transition from primarily requirements/ analysis to primarily design and implementation in each iteration.
在迭代开发中，每次迭代都会发生从以需求或分析为主要焦点到以设计和实现为主要焦点的转变

Provoking Early Change ★

尽早引发变更

It is natural to change some requirements during the design and implementation work, especially in the early iterations.
在设计和实现工作中，特别是在早期迭代中，发现和变更一些需求是很自然的，也是有帮助的
- Iterative and evolutionary methods “embrace change”
  迭代和进化式方法“包容变更”
- to have a more stable goal (and estimate and schedule) for the later iterations.
  以便在后期迭代中拥有更为稳定的目标（以及预算和进度）
- Early programming, tests, and demos help provoke the inevitable changes early on.
  尽早编程、测试和演示有助于尽早引发不可避免的变更
The discovery of changing specifications will both clarify the purpose of the design work of this iteration and refine the requirements understanding for future iterations.
发现规格说明变化既可以澄清本次迭代设计工作的目标，也可以精化对未来迭代的需求理解

Chap 13 Logical Architecture and UML Package Diagrams

Software Architecture ★

An architecture
the set of significant decisions about the organization of a software system,
the selection of the structural elements and their interfaces by which the system is composed
their behavior as specified in the collaborations among those elements,
the composition of these structural and behavioral elements into progressively larger subsystems,
the architectural style guides this organization, these elements and their interfaces, their collaborations, and their composition.
架构是一组重要决策，其中涉及软件的组织，对结构元素及其组成系统所籍接口的选择，这些元素特定于其相互协作的行为，这些结构和行为元素到规模更大的子系统的组成，以及指导该组织结构（这些元素及其接口、协作和组成）的架构风格

Logical Architecture ★

逻辑架构是

the large-scale organization of the software classes into packages (or namespaces), subsystems, and layers.
软件类的宏观组织结构，它将软件类组织为包（或命名空间）、子系统和层等
there’s no decision about how these elements are deployed across different operating system processes or across physical computers in a network (these latter decisions are part of the deployment architecture).
之所以称为逻辑架构，是因为并未决定如何在不同的操作系统进程或网络中物理的计算机上对这些元素进行部署（后一种决定是部署架构的一部分）

Layer Architecture ★★★

Layers in an OO system include: OO系统中通常包括的层有
- User Interface. 用户界面
- Application Logic and Domain Objects 应用逻辑和领域对象
  representing domain concepts that fulfill application requirements
  表示领域概念的软件对象（例如软件类Sale），这些对象现实了应用需求，例如计算销售总额
- Technical Services 技术服务
  provide supporting technical services, such as interfacing with a database or error logging. These services are usually application-independent and reusable across several systems.
  提供支持性技术服务的常用对象和子系统，例如数据库接口或错误日志。这些服务通常是独立于应用的，也可以在多个系统中复用
In network protocol stacks, a layer only calls upon the services of the layer directly below it (strict layered architecture).
在严格的分层架构中，层只能调用与其相邻的下层的服务。这种设计在网络协议栈中比较常见，而在信息系统中不太常见。
Information system usually has a relaxed layered architecture, in which a higher layer calls upon several lower layers
在信息系统中通常使用宽松的分层架构，其中较高层可以调用其下任意层的服务

Benefits of Using Layers ★★★

A separation of high from low-level services, and of application-specific from general services. This reduces coupling and dependencies, improves cohesion, increases reuse potential, and increases clarity.
使用层可以做到关系分离、高级服务和低级服务分离、特定于应用的服务与一般性服务分离。层可以减少耦合和依赖性、增强内聚性、提高潜在的复用性并且使概念更加清晰
Related complexity is encapsulated and decomposable.
封装和了解了相关的复杂性
Some layers can be replaced with new implementations. This is generally not possible for lower-level Technical Service or Foundation layers (e.g., java.util), but may be possible for UI, Application, and Domain layers.
某些层能够用新的实现替换。对于较低级的技术服务层或基础层来说不大可能（例如java.util），但是对UI、应用层和领域层来说是可能的
Lower layers contain reusable functions.
较底层包含可复用功能
Some layers (primarily the Domain and Technical Services) can be distributed.
某些层（主要是领域层和技术服务层）可以是分布式的
Development by teams is aided because of the logical segmentation
通过逻辑划分，有助于团队开发

Guideline: Model-View Separation Principle ★

Do not connect or couple model objects directly to view objects
don’t let a Sale object have a reference to a Swing JFrame window object. the windows are related to a particular application, while the non-windowing objects may be reused in new applications or attached to a new interface.
不要将非UI对象直接与UI对象连接或耦合。例如，不要让Sale软件对象（非UI“领域”对象）引用Java Swing JFrame窗口对象。因为窗口与某个应用相关，而（理想情况下）非窗口对象可以在新应用中重用或附加到新界面
Do not put application logic (tax calculation) in UI object methods. UI objects should only initialize UI elements, receive UI events, and delegate requests for application logic on to non-UI objects.
不要在UI对象方法中加入应用逻辑（例如税金的计算）。UI对象应该只初始化UI元素、接收UI事件（例如鼠标点击按钮）、将应用逻辑的请求委派到非UI对象（例如领域对象）

Model-View-Controller (MVC)

data objects (models), GUI widgets (views), and mouse and keyboard event handlers (controllers).
“MVC” has been applied on a large-scale architectural level. The Model is the Domain Layer, the View is the UI Layer, and the Controllers are the workflow objects in the Application layer.
A related pattern of this principle is the Observer pattern.
e.g. a JFrame window should not have a method that does a tax calculation. A Web JSP page should not contain logic to calculate the tax. These UI elements should delegate to nonUI elements for such responsibilities.

Object Modeling

Courseware

Elaboration - Detailed design - On to Object Modeling (Chap 14, Part III Elaboration Iteration I – Basic)
Elaboration - Detailed design - Dynamic Object Modeling (Chap 15, Part III Elaboration Iteration I – Basic)
Elaboration - Detailed design - Static Object Modeling (Chap 16, Part III Elaboration Iteration I – Basic)
Guideline: Entity-Control-Boundary Pattern (“实体－控制器－边界” 模式)

Chap 14 On to Object Design

How Much Time Spent Drawing UML Before Coding ★

For a three-week timeboxed iteration, 对于时间定量为三周的迭代

spend a few hours or at most one day (with partners) near the start of the iteration “at the walls” (or with a UML CASE tool)
在迭代开始时，应该“在墙上”（或利用UML CASE工具）花费几个小时或至多一天的时间，用于对有难度和创造性的部分绘制UML草图以得到其详细的对象设计
Then stop - and if sketching - perhaps take digital photos, print the pictures, and transition to coding for the remainder of the iteration
如果是草图的话，可能还需要拍摄和打印其数码相片。然后，在迭代的剩余时间里，
Using the UML drawings for inspiration as a starting point, but recognizing that the final design in code will diverge and improve.
以这些UML图形作为灵感的起点，将这些设计转化为代码，但还是要认识到代码中的最终设计会有分歧和改进
Shorter drawing/sketching sessions may occur throughout the iteration.
较短的绘图/草图活动可能会出现在整个迭代过程中

Designing Objects ★

There are two kinds of object models: dynamic and static. Spend a short period of time on interaction diagrams (dynamics), then switch to a wall of related class diagrams (statics).
对象模型有两种类型：动态和静态。
静态和动态建模之间据有关系，敏捷建模对此的时间是并行创建模型：花费较短时间创建交互图（动态），然后转到对应的类图（静态），交替进行。

Static Object Modeling ★

After first covering dynamic modeling with interaction diagrams, we then do the static object modeling. If the developers are applying the agile modeling practice of Create several models in parallel, they will be drawing both interaction and class diagrams concurrently.
最常见的静态对象建模是使用UML类图。在首先介绍使用交互图的动态建模后，我们会对此加以详细介绍。注意，如果开发者应用了并行创建若干模型的敏捷建模实践，则他们应该同时绘制交互图和类图。

Object Design Skill ★

The importance of object design skill is over UML notation skill
对象设计技能比UML表示法技能更重要
- What’s important is knowing how to think and design in objects, and apply object design best-practice patterns, which is much more valuable skill than knowing UML notation
  重要的是以对象进行思考和设计，并且应用对象设计的最佳实践模式；这与了解UML表示法极为不同，并且更具有价值
- Drawing UML is a reflection of making decisions about the design
  绘制UML反映了对设计作出的决策
While drawing a UML object diagram, we need to answer key questions:
- What are the responsibilities of the object? 对象的职责是什么？
- Who does it collaborate with? 对象在与谁协作？
- What design patterns should be applied? 应该应用什么设计模式？
- Far more important than knowing the difference between UML 1.4 and 2.0 notation! Therefore, the emphasis of the following chapters is on these principles and patterns in object design.
  回答这些问题远比了解UML1.4和2.0表示法之间的差异重要。因此，后续章节强调的重点是对象设计中的原则和模式

Fundamental object design ★★★

The object design skills are what matter, not knowing how to draw UML. Fundamental object design requires knowledge of:
对象设计技术并不一定要了解如何绘制UML。基本的对象设计需要了解的是：

principles of responsibility assignment 职责分配原则
design patterns 设计模式

Chap 15 UML Interaction Diagrams

Introduction ★

The UML includes interaction diagrams to illustrate how objects interact via messages.
UML使用交互图来描述对象间通过消息的交互。
sequence and communication interaction diagrams.
交互图的两种类型： 顺序图和通信图

Strengths and Weaknesses ★★

Example Sequence Diagram ★★★

makePayment消息被发送到Register的一个实例。没有指定发送者
Register实例将makePayment消息发送到Sale实例
Sale实例创建Payment实例

public class Sale {
  private Payment payment;
  public void makePayment(Money cashTendered) {
    payment = new Payment(cashTendered);
    // ...
  }
  // ...
}

Common UML Interaction Diagram Notation

Diagram Frames in UML Sequence Diagrams ★★

Iteration Over a Collection ★★★

A common algorithm is to iterate over all members of a collection (such as a list or map), sending the same message to each.
对集合（例如list或map）中所有成员进行迭代的常用算法是向每个成员发送同一条消息
Often, some kind of iterator object is ultimately used, such as an implementation of java.util.Iterator or a C++ standard library iterator, although in the sequence diagram that low-level “mechanism” need not be shown in the interest of brevity or abstraction.
在这种情况下，通常最终会使用某种迭代器对象，例如java.util.Iterator或C++标准库迭代器的实现，尽管在顺序图中为了简洁和抽象起见，无需表达这种低层的“机制”

Chap 16 UML Class Diagrams

Design Class Diagram (DCD) ★

The same UML diagram can be used in multiple perspectives
同一种UML图可以用于多种透视图

In a conceptual perspective the class diagram can be used to visualize a domain model.
在概念透视图里，类图可以用于将领域模型可视化
Class diagram is used in a software or design perspective, called design class diagram (DCD)
类图用于软件或设计角度时，称为设计类图（DCD）

Classifier ★

A UML classifier is “a model element that describes behavioral and structure features”.
UML类元是“描述行为和结构特征的模型元素”
Classifiers can also be specialized.类元也可以被特化
- They are a generalization of many of the elements of the UML, including classes, interfaces, use cases, and actors.
  它们是对众多UML元素的泛化，这些元素包括类、接口、用例和参与者
- In class diagrams, the two most common classifiers are regular classes and interfaces.
  在类图中，最常用的两个类元是常规的类和接口

Ways to Show UML Attributes ★★★

Ways to Show UML Attributes: Attribute Text and Association Lines 属性文本/关联线
Attributes of a classifier are shown several ways:
- attribute text notation, such as currentSale : Sale.
- association line notation
- both together
The full format of the attribute text notation is: visibility name : type multiplicity = default {propertystring} 属性文本表示法的完整格式
Guideline: Attributes are usually assumed private if no visibility is given
准则：如果没有给出可见性，则通常假设属性为私有的

Keywords ★

In general, when a UML element says it can have a “property string“ - such as a UML operation and UML association end have - some of the property string terms will be keywords used in the curly brace format
大部分关键字使用<<>>符号表示，但是有些关键词用大括号表示，例如{abstract}，这是包含了abstract关键字的约束。一般来说，如果UML元素声称具有“特性字符串”，例如UML操作和UML关联的端点，则其中一些特性字符串将是使用大括号格式的关键字（有些可能是用户定义的术语）

Generalization ★

Generalization in the UML is shown with a solid line and fat triangular arrow from the subclass to superclass
在UML中，泛化用由子类到超类的实线和空心三角箭头表示
- A taxonomic relationship between a more general classifier and a more specific classifier.
  泛化——普通的类元与特殊的类元之间的分类学关系
- Each instance of the specific classifier is also an indirect instance of the general classifier.
  特殊类元的每个实例也是普通类元的间接实例
- Thus, the specific classifier indirectly has features of the more general classifier.
  因此，特殊类元间接拥有了普通类元的特性
Generalization -> inheritance?
泛化与OO编程语言（OOPL）中的继承的意义是否相同？
- It depends. In a domain model conceptual-perspective class diagram, the answer is no.
  视条件而定。在领域模型概念视角的类图中，答案为否
- In a DCD software-perspective class diagram, it implies OOPL inheritance from the superclass to subclass.
  在DCD软件视角的类图中，其意为由超类到子类的OOPL继承

Composition Over Aggregation ★★

组合优于聚合

Aggregation is a vague kind of association in the UML that loosely suggests whole-part relationships
聚合是UML中一种模糊的关联，其不精确地暗示了整体-部分关系
- It has no meaningful distinct semantics in the UML versus a plain association, but the term is defined in the UML. Why?
  虽然在UML中并没有可以区分聚合与纯关联的语义，但是UML还是定义了这一术语。为什么？
- In spite of the few semantics attached to aggregation, everybody thinks it is necessary (for different reasons). Think of it as a modeling placebo. [RJB04]
  虽然并没有给聚合赋予太多的语义，但是每个人（基于不同的理由）都认为这是必要的。可以将其视为建模的安慰剂。
Guideline: Therefore, following the advice of UML creators, don’t bother to use aggregation in the UML; rather, use composition when appropriate
不要在UML中费心去使用聚合。相反，在适当的时候要使用组合

Design Objects with Responsibilities

Courseware

Design Objects with Responsibilities (Chap 17, Part III Elaboration Iteration I – Basic)

Chap 17 GRASP: Designing Objects with Responsibilities

Outputs of Object Design ★

UML interaction, class, and package diagrams for the difficult parts of the design that we wished to explore before coding
我们期望在开始编码之前针对设计中的难点创建UML交互图、类图和包图
UI sketches and prototypes
UI的草图和原型
database models with UML data modeling profile notation.
数据库模型
report sketches and prototypes
报表的草图和原型

Responsibility-Driven Design

Responsibility as contract or obligation of class [UML]. ★★★
- Doing responsibilities of an object
  对象的行为职责包括：
  - doing something itself, such as creating an object or doing a calculation
    自身执行一些行为，如创建对象或计算
  - initiating action in other objects
    初始化其他对象中的动作
  - controlling and coordinating activities in other objects
    控制和协调其他对象中的活动
- Knowing responsibilities of an object include:
  对象的认知职责包括
  - knowing about private encapsulated data
    对私有封装数据的认知
  - knowing about related objects
    对相关对象的认知
  - knowing about things it can derive or calculate
    对其能够导出或计算的事物的认知
Responsibilities are assigned to classes of objects during object design. ★★★
在对象设计中，职责被分配给对象类
- a Sale is responsible for creating SalesLineItems” (doing)
- a Sale is responsible for knowing its total (a knowing).
Guideline: Domain objects illustrate the attributes and associations, relevant responsibilities related to “knowing.” ★
准则：对于软件领域对象来说，由于领域模型描述了领域对象的属性和关联，因此其通常产生与”认知“相关的职责
- if the domain model Sale class has a time attribute, that a software Sale class knows its time.
Big responsibilities take hundreds of classes and methods. Little responsibilities might take one method. ★
职责的粒度会影响职责到类和方法的转换。大粒度职责具有数百个类和方法。小粒度职责可能只是一个方法
- the responsibility to “provide access to relational databases” may involve two hundred classes and thousands of methods.
- the responsibility to “create a Sale” may involve only one method in one class.

Low Coupling ★★★

Problem
- How to support low dependency, low change impact, and increased reuse?
Solution
- Assign a responsibility so that coupling remains low. Use this principle to evaluate alternatives.
  分配职责以使（不必要的）耦合保持在较低水平。用该原则对可选方案进行评估
Coupling
- a measure of how strongly one element is connected to, has knowledge of, or relies on other elements.
  耦合是元素与其他元素的连接、感知及依赖的程度的度量
- An element with low coupling is not dependent on too many other classes, subsystems, systems.
  低耦合往往能减少修改软件所需要的时间、工作量和缺陷
- High coupling problems:
  - Forced local changes because of changes in related classes.
  - Harder to understand in isolation.
  - Harder to reuse because its use requires the additional presence of the classes on which it is dependent

Controller ★★★

Problem: What first object beyond the UI layer receives and coordinates (“controls”) a system operation? 在UI层之上首先接收和协调（“控制”）系统操作的对象是什么——控制器

A controller is the first object beyond the UI layer that is responsible for receiving or handling a system operation message.
System operations were first explored during the analysis of SSD. These are the major input events upon our system. e.g.,
- when a cashier using a POS terminal presses the “End Sale” button, he is generating a system event indicating “the sale has ended.”
- when a writer using a word processor presses the “spell check” button, he is generating a system event indicating “perform a spell check.”

Contents

Introduction of SE & OOAD

Courseware

Key Point of Software Engineering ★

Software Engineering Definition ★★★

History of Software Engineering

Software Engineering Body of Knowledge

Software LifeCycle

Software Process Improvement for Enterprise

Key Point of Courseware

Software Quality & Custom Experience

Analysis vs. design ★

Object vs. Class

Chap 1 Object-oriented Analysis and Design ★

UML (Unified Modeling Language) ★

UP Unified Process and Agile

Courseware

软件团队管理基础

知识分子的管理要点与艺术

目标管理

软件团队组织模型

软件开发过程模型

CMMI五个级别

Waterfall Model 瀑布模型 ★

增量模型

原型与螺旋模型

Chap 2 Iterative, Evolutionary, and Agile

Unified Process ★ 统一过程

Unified Process Workflows ★★

Use-Case-Driven ★★

Architecture Centric ★★

Iterative and Evolutionary ★★

Agile Methods and Attitudes ★

Agile Modeling ★

Unified Process Phases ★

Artifacts, Workers, and Activities ★

Assignment

CMU与美国国防部合作提出CMM/CMMI模型，解决了美国国防部什么问题？它对软件产业的作用是什么？

简述瀑布模型、增量模型、螺旋模型（含原型方法）的优缺点。

瀑布模型

增量模型

原型与螺旋模型

简述RUP的三大特点，其中哪些内容体现了用户驱动的开发，哪些内容体现风险驱动的开发？

以用户为驱动

以体系结构为中心

迭代、增量式开发

RUP四个阶段的划分准则是什么？关键的里程碑是什么？

IT项目管理中，“工期、质量、范围/内容”三个元素中，在合同固定条件下，哪个最容易与客户达成妥协？理由？

RUP为企业按固定节奏生产、固定周期发布软件产品提供了依据，为什么？

（可集体讨论）讲述软件开发中 1-2个有效的敏捷实践，以及依据。

（可集体讨论）选择一个可追溯到初始版本的软件，如“知乎”，你认为实现当初类似“stack-overflow”这类问答模式的软件，需要多少人，多少月？

Inception & Business Modeling

Courseware

Chap 4 Inception is Not the Requirements Phase

Chap 5 Evolutionary Requirements

UseCase Modeling

Courseware

Chap 6 Use Cases

Actors(参与者) ★★

Use Case(用例) ★

Use Case Modeling(用例模型) ★

Three Common Use Case Formats ★

Guideline: How to Write Use Cases ★

Guideline: How to Find Use Cases ★★★

应用UML：用例图

应用UML：活动图 ★★★

应用UML：状态图

Domain Modeling

Courseware

Introduction ★

Domain Model

Guideline

Create a Domain Model

Find Conceptual Classes ★★

Report Objects Include ‘Receipt’ in the Model ★★

A Common Mistake with Attributes vs. Classes ★★

When to Model with ‘Description’ Classes ★★

Association ★

Guideline

Perspectives: Will the Associations Be Implemented In Software?