CPT203 软件工程开发 笔记

Software Engineering
By Prof. Fazal Rehman Shamil
可以在这个网站速览概念x

Activity Diagram

活动图
菱形表示OR，黑心粗线表AND也表同时开始
黑圆点表程序开始，黑圆点外套圈表程序结束
上方泳道表示不同执行者

解题注意所有动词，副词

形如：

Use Case Diagram

用例图
实心箭头表示泛化，直线端与三角端做的内容相似，但内容更多。
虚线extend箭头线端表示可能会进行的活动，

虚线include箭头三角端表示一定被包含在内的活动。

形如：

Class Diagram

类图
去除某些潜在类的理由：

• Not Retained information，如果潜在类是环境等“Bank，Store”不存储任何信息的对象，则Failed。
• Not Needed services，
• Single attribute，如果潜在类可为其他类的属性，则Failed，画图时写在类的属性栏里
• Synonym，潜在类是别的类的同义词

实心箭头直线端是三角端的子类。

实心直线两头加数字省略号表示关联修饰

空心菱形+实线表示聚合aggregation，表示整体和个体的关系，属于不同层次，菱形端表示整体，“consist of”，“starts”

实心菱形+实线表示合成composition，是普通的聚合关系中代表整体的对象也负责代表部分的对象的生命周期（同年同月同日死），“record”等词语，同时record还可能表示属性，属性的话可能在潜在类那就被筛选掉了。

解题步骤先筛选潜在类Potential Classes，再写关系Relationship，最后画图

形如：

State Diagram

圆角矩形内是状态，实心箭头旁附动作，[ ]表示动作进行时的额外条件，动作或额外条件引起状态改变。
黑圆点表程序开始，黑圆点外套圈表程序结束
表项entry/do/exit表示进入状态/状态中/退出状态时执行的操作。
大方框可包含数个状态来表示一个大状态

形如：

Sequence Diagram

老师说期末不考这个
实心箭头表主动，虚线箭头表相应
竖着的虚线表示准备着，竖着的粗线表活动时期

形如：

JUNIT

注意@Test 和 变量初始化 和 异常检测里的 .class 和 ()->

Java loosely Coupled 低耦合

减少组件内容间的交叉

代码1：

优化后，把求和放到各个class中，求总和的时候调用求和函数

代码2：右边是优化后
建立了IMessageService接口用于发送信息，Customer的目的是发消息不是只能使用邮件发消息，在CustomerService里建立起Customer和邮件的使用关系。

week1

介绍课程

week1总览
什么是软件工程：
“Computer software is the product that software professionals build and then support over the long term. It encompasses computer programs and associated documentation that execute within a computer of any size and architecture . Software products may be developed for a particular customer or may be developed for a general market.”

两种软件工程：
Generic software products 大众化的通用产品
Customized software products 定制产品

软件工程的四种性质：
Maintainability
Dependability and security
Efficiency
Acceptability

SOFTWARE DETERIORATION软件退化
按理说软件不会产生物理器械那种机械磨损，但是软件与需求紧密相关，随着时间过去，可能有部分设计理念或功能不符合新环境，造成Failure rate的徒增。这使得我们要持续地去维护一个软件

软件工程的开发周期（Software Process）：
• Software specification
• Software development
• Software validation
• Software evolution

然后说了开发软件工程很复杂
Software engineering is a systematic approach to the production of software that takes into
account practical cost, schedule, and dependability issues, as well as the needs of software
customers and producers.

最后谈论了道德问题，数据之类的

week2 Software Process

什么是Software Process软件过程：

A software process is a set of related activities that leads to the production of a software product所有软件过程都包含以下活动

1. Fundamental process activities功能性活动：
   • Software specification (Requirement engineering)
   • Software design and implementation (Software development)
   • Software validation (Software testing)
   • Software evolution
2. Supporting activities支持性活动：
   • Documentation
   • Software configuration management
   • Risk management

进行以上活动的两种方法：
• Sequential approach： specification→development→validation→evolution
• Iterative approach：需求什么去做什么，version1.0→2.0→3.0

2 major types of systems：
• Critical systems（多指操作系统，采用sequential approach，指需求很明确的那些系统，往往是计划型）
• Business systems （采用iterative approach，业务灵活变换，对于这些系统，灵活的process更有效，往往是敏捷型）

2 major types of software process
• Plan-driven：计划型 “All process activities are planned in advance”，，采用sequential approach
• Agile processes：反应型，“Planning and development is incremental and iterativei” ， 采用terative approach

	需求不变	需求多变
软件过程的分类	Plan-driven processes>Agile processes	Plan-driven processes
被软件开发的系统分类	Critical systems>Business systems	Critical systems
软件过程的实行方法的分类	Sequential approach>Iterative approach	Sequential approach

如何选择相应的方法和模型：
需求是否了解（未来是否会增加新的需求），需求是否会经常变更，迭代版本是否困难（Embedded嵌入式产品迭代成本大），是否有可用的重组模块，开发周期是否紧迫。

Software process models

将项目的进程转换为肉眼可见的软件开发模型，使得对项目的进度和表现更直观，利于管理。
What is software process models?

1. Waterfall model
2. Incremental development
3. Reuse-oriented software engineering
   模型间可以互相组合

Waterfall model瀑布模型

瀑布模型
Plan-driven processes计划型开发，每个环节完成后才进入下一个环节，每个环节都有相应的document使得管理者能更直观的掌握进度，如果环节出问题则返回上一个环节（例如系统测试环节出现问题就返回上一个环节重新测试单元）。在最终环节之后，软件投入正式使用，同时收集错误和新的用户需求，系统必须不断发展，某些更新可能会重复之前的过程。

因为文档的生成和批准成本和大量返工成本，进行少量迭代后可将部分环节冻结（如第一个环节），节约不必要耗费的资源。（但是过早冻结部分环节会使系统无法实施部分用户需求）。

优点：

1. 当委托别的公司开发软件时，瀑布模型很有用，可以提供formal and complete documentation,发生纠纷时很好用。
2. for large,complex, long-lifetime systems 对于长期维护的项目，documentation能提供长久的维护支持

缺点：

1. the inflexible partitioning of the project into distinct stages.
2. Commitments must be made at an early stage in the process, which makes it difficult to respond to changing customer requirements.

In principle, the waterfall model should only be used when the requirements are well
understood and unlikely to change radically during system development.

Incremental development 增量开发

敏捷开发，迭代开发，增量开发
Iterative approach，采用迭代的方式，功能性活动高度集中，版本可以在短周期内实现更迭，并且在每次更迭时添加一些功能。开发和验证活动交叉进行，增量开发是敏捷开发的基本组成，对于电子商务和个人系统，增量比瀑布要好。

在早期版本即可达成用户需求的主体框架，以便用户指出未达标的需求或提出修改建议，对于需求变更的修改代价减少（及时响应），可以及时相应变更要求，因此越是重要的需求越能提前登录版本，并在后期完善。

与瀑布模型相比，优点：

1. The cost of accommodating changing customer requirements is reduced.
2. It is easier to get customer feedback on the development work that has been done.
3. More rapid delivery and deployment of useful software to the customer is possible, even if all of the functionality has not been included.

缺点：

1. The process is not visible.
2. System structure tends to degrade as new increments are added.
3. large organizations have bureaucratic procedures that have evolved over time and there may be a mismatch between these procedures and a more informal iterative or agile process
4. Formal procedures are required by external regulations (e.g., accounting regulations)

Reuse-oriented software engineering 面向复用的软件开发

译文：面向复用的软件开发
原文：software reuse oriented software engineering

使用可重用组件(reusable component)和集成框架进行改造（继承、适配）、配置、拼装、组合等手段完成软件的局部功能开发。

因为大部分组件是由第三方开发，所以第三环节需要对原本的需求进行修订

可复用组件的三大分类：

1. Web services that are developed according to service standards and which are available for remote invocation.
2. Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE.
3. Stand-alone software systems that are configured for use in a particular environment.

优点：

1. reducing the amount of software to be developed and so reducing cost and risks.
2. usually also leads to faster delivery of the software.

缺点：

1. requirements compromises are inevitable and this may lead to a system that does not meet the real needs of users.
2. some control over the system evolution is lost as new versions of the reusable components are not under the control of the organization using them.第三方组件的所有权位于别人手上，没法控制第三方组件
   

Software Process Activities

• Real software processes are interleaved sequences of technical, collaborative, and managerial activities with the overall goal of specifying, designing, implementing, and testing a software system.

这节主要介绍这些activities是什么（所有软件过程都包含以下活动）

1. Software Specification
   定义：the process of understanding and defining
   目标：produce an agreed requirements document that specifies a system satisfying stakeholder requirements.
   细化过程：
   • what services are required from the system
   • identifying the constraints on the system’s operation and development.
   不同人群的requirement不同：
   • End-users and customers need a high-level statement of the requirements;
   • system developers need a more detailed system specification.
   这个阶段出问题会极大影响后续项目进度
   

2. Software Design and Implementation
   定义：the process of converting a system specification into an executable system将软件规范转换为可执行软件
   目标：A software design is a description of the structure of the software to be implemented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used.

设计的输出因模型和系统而异，如果是critical system，因该编写详细的文档和系统描述；如果使用了model-driven，设计结果可能是图表；如果使用agile methods，设计结果可能体现在代码中

3. Software Validation
   Verification and validation (V & V)
   目标：to show that
   • a system both conforms to its specification
   • it meets the expectations of the system customer
   1. Program testing（the system is executed using simulated test data）
      • Development testing
      • System testing
      • Acceptance testing
   2. Validation（Validation may also involve checking processes, such as inspections and reviews, from user requirements definition to program development）
      • Inspection（在软件的实现过程中而不是测试后也可以进行检查）
      • Review

三种测试：Development testing，System testing，Acceptance testing
通常测试与开发是交叉进行的，开发新版本时需测试其功能，有的critical system开发有专门的测试组

4. Software Evolution
   硬件的更改要比软件的更改更加复杂
   人们认为软件开发software development和软件维护software evolution (software maintenance)是分开的。
   总之，与其分开考虑，还是考虑软件工程更为现实。

week3 Agile Framework敏捷开发

什么是RAPID SOFTWARE DEVELOPMENT：

• The software is not developed as a single unit but as a series of increments,
  with each increment including new system functionality.
  .
  Fundamental characteristics功能特性：
  • The processes are interleaved交错.
  • Minimum documentation极少的文档，而不是没有文档
  • Developed in a series of versions, or increments, with system stakeholders involvement.
  • System user interfaces are often developed using an interactive development system that allows the interface design to be quickly created

为什么需要RAPID SOFTWARE DEVELOPMENT：

• Businesses now operate in a global, rapidly changing environment. They have to respond to new opportunities and markets, changing economic conditions, and the emergence of competing products and services
  简单来说就是快速做出雏形，快速部署到实际应用，让客户知道软件的作用效果，根具实际体验得到的改进建议和问题改进

之前研究的计划驱动过于冗长，不适应这种需要快速出效果的软件：
PLAN-DRIVEN DEVELOPMENT APPROACH计划驱动实现
适用于大型长期维护软件，如需要多团队合作研发；需要研发出一个严格系统；有许多不同的人参加维护
Large, long lived software - careful project planning, formalized quality assurance, the use of analysis and design methods supported by CASE tools, and controlled and rigorous software development processes

AGILE METHODS 敏捷开发方法

1. 更专注于软件，而不是设计和文档
2. 普遍依赖于incremental approach
3. 非常适合于需求在开发周期内频繁变化的情况，欢迎变更需求
4. 目的在于快速交出第一代软件，收到新的需求和回馈后，应用到系统迭代中

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

敏捷开发在施行时会遇到的不如人意之处：

1. 理想中的客户是乐于花时间和开发团队交换意见的，并且可以掌大权(represent all system stakeholders)
2. 个体开发人员要经验充足，同时确保设计和程序和质量
3. 更新优先级很难抉择，尤其是权力分散的客户(没法一语成谶）
4. 保持简化需要额外工作(最简单的是最难的）
5. 客户可能需要的是完整的，有文档的，设计明确的开发流程和产品
6. 软件需求文档是大多合同要求之一
7. 增量方法是敏捷开发固有的，合同会比较难写
8. 敏捷开发必须依赖于合同，费用应该算上开发所用时间，而不是一组特定的需求
9. 如果出现问题，很难追查责任人

如何考虑是否使用敏捷开发：

1. Are systems that are developed using an agile approach maintainable, given the emphasis in the development process of minimizing formal documentation?
2. Can agile methods be used effectively for evolving a system in response to customer change requests？

敏捷开发的维护：

1. 敏捷开发支持者认为文档不重要
2. 重要的是代码的质量和易读性
3. 系统需求文档是关键文档，可以告诉工程师系统应该做到什么
4. 客户需要投入维护
5. 没有详细文档，代码理解会基于团队成员本身的理解。当人员发生变动，新人员很难理解系统

混合使用计划型驱动和敏捷开发（这个问号忒抽象了

敏捷开发的例子 Scrum框架

Roles角色

Scums由一个或多个Scrum小组组成

每个小组包含三种成员角色{

Product owner：决定这一代产品的研发方向和顺序
ScrumMaster：确保小组基于Scrum框架进行创造和按照规定流程作业
Development team：决定如何交付Product Owner提出的要求
}

ScrumMaster{

1. 确保每个人理解并实现Scrum values, principles, and practices
2. 充当教练和领导地位，帮助组织organization和小组完美表现，实现公司个性化的Scrum方法
3. 帮助机构解决Scrum过程中的管理层变动
4. 作为促进者facilitator，帮助团队解决问题，改进Scrum
5. 阻止外来干扰
6. ScrumMaster无权控制团队，与传统框架里的项目经理或开发经理角色不同
7. Functions as a leader, not a manager
   }

Product Owner{

1. 负责决定构建哪些特性和功能以及顺序
2. 向其他参与者清除地传达Scrum小组将要实现怎样的产品clear vision
3. 负责开发或维护方案的成功
4. 确保执行最有价值的工作
5. 负责与ScrumMaster和开发团队合作
6. 负责解答提交上来的问题

}

Development Team{

1. 开发团队的每个人都是全能选手（ designing, building, and testing），因此整个团队专业范围广泛交叉（a diverse, cross-functional）
2. 可以自行决定如何实现product owner提出的目标， self-organize
3. 5-9人
4. 每个人都得是全能选手
5. 开发需求大规模小组时，小组内可以细分小组
   }

Activities活动

使用increment快速迭代（每次迭代称作一次sprint），每次迭代出满足若干个需求的新版本。
sprint将会被分割成许多小任务，product backlog - sprint planning - sprint backlog - sprint execution (daily scrum) - potentially shippable product - sprint review product - sprint retrospective process

(PPT 上的Forecast? Commitment? 不是这学期内容）

Product Backlog{

product owner负责根据团队和利益相关人的消息，然后确定和管理工程（product backlog items）的顺序，以优先级列表prioritized list的形式表现，称为product backlog。

product backlog grooming：
创建和细化(询问详细)产品待办事项、对其进行评估并确定其优先级的活动称为梳理
The activity of creating and refining product backlog items, estimating them, and prioritizing them is known as grooming
因为需求会变，所以一开始的梳理只梳理顶层

1. 在新产品研发中（new-product development），product backlog起初是为了用于确保实现product owner需求的。
2. 在正在进行的研发中（ongoing product development），它还可以包含新功能，修改功能，修改问题，技术改进等。
3. product owner需要与内部和外部利益相关者（ internal and external stakeholders）合作，收集和定义product backlog
4. 高价值对象在顶层
5. 它是一个不断变化的结构，随着条件变化，或者随着团队对scrum的理解，product owner可以增删改它
6. 实际应用中，许多团队使用相对度量来衡量子项目对象大小（use a relative size measure such as story points or ideal days to express the item size）
   

}

PBI Example{
用户说的需求，用户的描述，验收标准
product owner需要对以下PBI排列优先级并告知达成这个需求需要的时间

}

Sprint{
在Scrum中，工作以迭代的方式以sprints表现，形式类似time box

1. 每个sprint应该为客户或用户创造价值
2. 每个sprint都有固定的开始和结束日期
3. 通常每个sprint的周期长度是相同的
4. 前一个sprint结束立刻下一个sprint开始

}

Sprint Planning{在sprint开始前

1. PBI可能代表数周或数月的工作。为了完成PBI中的所有项目，需要进行一系列的sprint
2. 为了确定要在下一个sprint中构建的最重要的PBI子集，product owner、开发团队和ScrumMaster执行sprint规划
3. 在sprint规划期间，product owner和开发团队就sprint目标达成一致，该目标定义了即将到来的sprint应该实现的目标
4. 基于sprint目标，开发团队审查PBI，并确定团队可以在即将到来的sprint中以可持续的速度实际完成的高优先级项目
5. 许多团队将每个目标拆分成小任务，这些小任务被称为sprint backlog
6. 团队预估小任务的用时和分配，effort hour指一周内总计用在该task上的时间
   
   }

Sprint Execution{

1. 一旦Scrum团队完成sprint规划并就下一个sprint的内容达成一致，开发团队将开始执行所有任务级工作以完成需求
2. 完成意味着有高度的信心，生产高质量功能
3. 团队成员定义自己的任务级工作，然后以他们认为最有利于实现sprint目标的任何方式进行自我组织
   }

Daily Scrum{

1. 开发团队成员每天举行一次15分钟以下的scrum
2. 也被称为daily stand-up，站着开会提高简洁性，它不是正式会议，不是问题方案研讨会。
3. 每个人回答三个问题：上次scrum之后我做了什么，这次计划做什么，目前有什么困难。便于让成员了解正在发生的事情大局。
4. 交流sprint backlog的items的状态
5. It is an inspection, synchronization, and adaptive daily planning activity that helps a self-organizing team do its job better.
   }

Definition of Done{怎样才能算做好了

1. sprint的结果是一个潜在的可交付产品增量（potentially shippable product increment），这意味着Scrum团队根据一致赞同的定义来“完成”了一开始打算做的任何事情
2. 该定义规定了工程质量优秀且可交付的信心。
3. 对Done的最低限度的定义应是“设计、构建、集成、测试和文档”的完整产品
4. “潜在的可交付性”并不意味着建造的东西必须可实际交付，仅从技术层面上讲。
5. 交付（shipping）是一项商业决策，含有较多的风险，所以需要更多迭代。它经常受到以下因素的影响：
   •我们是否有足够的功能或足够的客户工作流程来证明客户部署的合理性？
   •鉴于我们在两周前刚刚发布了一个版本，我们的客户能否接受另一个变化？
   }

Sprint Review{

1. Sprint review is to inspect and adapt the product that is being built.
2. 关键是和参与者交流，包括 Scrum team, stakeholders, sponsors, customers, and interested members of other teams.
3. 专注于结合总体开发，审查这次迭代中完成的功能
4. 每个人都知道发生了什么，并有机会帮助知道即将到来的开发，确保创建最适合的解决方案
   }

Sprint Retrospective{

1. 冲刺回顾是检查和调整流程的机会
2. 开发团队，ScrumMaster，和产品负责人讨论哪些环节与{Scrum以及相关的技术实践}配合的好与不好
3. 重点是进行持续的流程改进
4. 在sprint Retrospective结束时，Scrum团队应该确定并致力于一些实际的流程改进
   }

Artifacts产出

week4 Requirements

软件过程的第一步是软件需求分析
什么是需求：

1. 需求定义了一个系统应该做什么
2. Requirement engineering(RE) 既是发现分析归档检查需求和约束的过程
   The process of finding out, analyzing, documenting and checking these needs and
   constraints is called requirements engineering (RE)
3. 可以被划分为抽象 a high-level, abstract statement和具体定义 a detailed, formal definition
   a high-level, abstract statement of a service that a system should provide or a constraint on a system OR detailed, formal definition of a system function

需求的抽象与具体：

1. As part of a contract for a large software development project, it must define its needs in a sufficiently abstract way
2. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do

不同程度的具体服务于不同方的需求：

1. User requirement：自然语言的语句加上描述系统服务和约束的图标（负责人说的话
2. System requirement：更多的和软件系统函数，服务和操作上的使用限制（代码函数实现，接口什么的

谁会去看这些需求

Functional and None-functional Requirements:
Software system requirements被划分为：

1. Functional requirements： These are statements of services the system should provide. How the services should react and behave in certain condition. In some cases, the functional requirements may also explicitly state what the system should not do。
2. Non-functional requirements These are constraints on the services or functions offered by the system. Non-functional requirements often apply to the system as a whole, rather than individual system features or services.
3. 

Functional Requirement

1. When expressed as user requirements, functional requirements are usually described in an abstract way that can be understood by system users.
2. More specific functional system requirements describe the system functions, its inputs and outputs, exceptions, etc., in detail.
3. The functional requirements specification of a system should be both complete完整 and consistent一致.
   • Completeness means that all services required by the user should be defined.
   • Consistency means that requirements should not have contradictory definitions.
4. 实际应用中，对于 large, complex systems, 不太可能以完整一致的方式实现需求
   • it is easy to make mistakes and omissions when writing specifications for complex systems
   • there are many stakeholders in a large system. Stakeholders have different and often inconsistent needs.
   

Non-functional Requirement

1. Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific services delivered by the system to its users.非功能性需求是与系统提供的服务不直接相关的需求

• System properties系统属性： such as reliability, response time, and store occupancy.
• Constraints on the system implementation系统评估标准： such as performance, security, or availability.

2. 通常将系统作为约束评估的整体，实现非功能性需求往往比实现单个具体功能更关键，未达成某一个非功能性需求可能会使整个系统不可用
3. The implementation of non-functional requirements may be intricately disperse throughout the system.
   非功能性需求的实现分散
   • They may affect the overall architecture of a system rather than the individual components.影响整个架构
   • A single non-functional requirement may generate a number of related functional requirements.会牵扯出大量相关性的功能性需求

Non-Functional Requirements 的分类：

1. Product requirements - These requirements specify or constrain the behavior of the software.指定软件功能
2. Organizational requirements - These requirements are broad system requirements derived from policies and procedures in the customer’s and developer’s organization.顾客和开发人员提出的系统需求
3. External requirements - This broad heading covers all requirements that are derived from factors external to the system and its development process。开发过程中衍生的所有需求

Non-Functional Requirements 的困难：

1. 使用者或客户会使用笼统的大概的自然语言来形容这些需求（速度快，大小小，易于使用，可靠等词语）
2. 非功能性需求会影响和冲突其他的功能性或非功能性需求。
3. 在项目文档中很难区分功能性与非功能性→需要在文档中高亮重要的系统属性的相关内容，如性能和可靠性

The Software Requirements Document软件需求文档:

又名Software Requirements Specification or SRS，应当包括用户对系统的需求和详细的系统需求说明both the user requirements for a system and a detailed specification of the system requirements

• 当外部承包商outside contractor开发系统时，SRS是必要的
• 如果使用敏捷开发，敏捷开发的需求更新过快，完整的SRS会快速过时。不过可以编写一个简短的支持文档，定义系统的业务和可靠性需求
• 通常用以下特性衡量SRS质量：• Correct • Complete • Unambiguous • Verifiable • Consistent • Ranked for importance and/or stability • Modifiable • Traceable
• level of detail in requirement，需求的详细与否因所应用的系统而异
  • Detailed requirements（Critical systems，system is to be developed by a separate company）
  • Less detailed requirements（inhouse，iterative development process）

Requirements Specification：
定义：在需求文档中记录user和system需求的过程
标准：

• 需求必须表达清楚，不混淆，易于理解，完整且一致
• user requirements需要用通俗易懂的话语描述功能与非功能性需求
• 命令型词语较为规范，如shall must required，而不是may will should这类弱词语（Weak phrases），弱词语的占比表示文档模糊程度
• 仅描述系统的外部行为，不涉及内部实现，系统架构或设计细节
• 使用自然语言，简单的表格和表单编写用户需求
• System requirements是user需求的扩展
• 为用户需求添加细节，系统如何实现用户需求
• 可作为合同contract的一部分
• 描述系统的外部行为以及实施约束，不应当关心系统如何设计或实施。

问题：

• stackholder甲方提要求的时候存在冲突和不一致 – inherent conflicts and inconsistencies
• 实际应用中，REQUIREMENTS SPECIFICATION不太可能包含所有设计信息，有以下理由

1. 可能要构建系统的初始架构，系统需求由子需求组织成
2. 系统可能需要与现有系统交互，会限制对新系统的功能追加
3. 对于某些非功能性需求，需要使用特定架构

**Requirements Specification **自然语言表述natural language：
It is expressive, intuitive, and universal.
But it is also potentially vague, ambiguous, and its meaning depends on the background of the reader。
为了减少误解，需要规定标准格式，区分强制要求和可选要求，要求高亮关键部分，不假设读者有专业背景等。

**Requirements Specification **结构化语言表述structured：
将自然语言放进规定的结构或模板中编写系统需求
将需求归为card，每张card上包含需求理由，对其他需求的依赖，用以支持需求的材料等

整个需求分析过程是一个活动交错的迭代的过程iterative process in which the activities are interleaved.
system requirement比user的需求更加细节

REQUIREMENTS ELICITATION AND ANALYSIS需求获取与分析：
软件工程师与客户与用户一起寻找： •应用领域（水果店卖水果，数码店卖数码）•系统应提供哪些服务•系统所需的性能（高吞吐或低延迟）•硬件约束等
组织中有各种各样的人员：终端用户，开发维护工程师，业务经理，领域专家，工会代表trade union representatives.
发展：在不断地迭代中，随着活动之间的交互，系统变得越来越适合本地因素（员工知识，模型架构，标准设定等）
困难：从甲方那里获得并理解需求很困难：

1. 甲方自己不知道如何描述需求，他们可能会提出不切实际的要求，因为他们不知道什么是可行的，什么是不可行的。
2. 甲方用自己不明确的知识去表述需求
3. 不同的甲方有不同的方式去表达需求，有些需求互相冲突
4. 政治因素会影响系统需求
5. 商业环境动态变换时需求也会产生改变

上图中

1. Requirements discovery： This is the process of interacting with stakeholders of the system to discover their requirements
2. Requirements classification and organization： This activity takes the unstructured collection of requirements, groups related requirements, and organizes them into coherent clusters.
3. Requirements prioritization and negotiation： When multiple stakeholders are involved, requirements will conflict. This activity is concerned with prioritizing requirements and finding and resolving requirements conflicts through negotiation.
4. Requirements specification： The requirements are documented and input into the next round of the spiral.

需求发现Requirements discovery：

需求发现（有时称为需求获取）是收集有关所需系统和现有系统的信息，并从这些信息中提取distilling用户和系统需求的过程。

• 获取来源： documentation, system stakeholders, and specifications of similar systems. • interviews • observation • scenarios • prototypes
• 其中，甲方stakeholder包括终端用户到管理者，到外部甲方，如监管机构

需求发现： Interview采访
含义：与甲方的正式或非正式访谈
过程：需求工程团队向甲方提出系统的问题，从回答之中发现需求
分类：

1. Closed interviews-甲方回答提前准备好的问题
2. Open interview- 没有预先确定的议程no pre-defined agenda

作用：

1. 搞懂甲方要干什么
2. 他们要如何使用新系统
3. 他们使用旧系统的不便

难处：

1. 应用领域专家都使用特定于某个领域的术语，容易让工程师误解。
2. 某些领域对甲方来说过于熟悉，所以会不值一提或觉得较难向外解释
3. 没法有效获取需求，人之间存在复杂的权力关系（subtle power relationships），不愿谈论会影响需求的政治和组织问题

要求采访者有以下特质：

• open-minded, avoid pre-conceived ideas about the requirements, and are willing to listen to stakeholders.（性格好
• can prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system. （嘴皮子好

需求发现：Scenarios假想情节
含义：系统用户可以知道自己将如何与软件系统交互，每个情节描述与系统的交互，通常覆盖系统的一个或多个功能
作用：

1. 假想使用情形，基于此的讨论结果可以帮助理解系统需求
2. 与甲方合作，将情景中的细节整理成文本，图标。或使用结构化记录的方法

过程：情节开始于模糊的大概交互，随着启发elicitation process，细节被逐渐添加

需求发现：Use cases用例：
定义：是一种需求发现技术，简单来说，用例识别参与交互的参与者和命名与之相关的交互.
使用high-level的文档存储，记录所有可能出现的交互。（一个case装一个scenario，或者一个case装多个scenario）
扩展：可由额外的描述系统交互的信息补充，如文本，图型
不足：不适用于constraints，high-level business，nonfunctional requirements，domain requirements.

上图：use cases指椭圆状的需求或功能，这些人被称为external entity外部实体

需求发现：Ethnography（人情世故

1. 系统需求诞生于社会和组织环境，由环境衍生或约束
2. 系统成功的关键是满足这些社会需求
3. 这是一种观察技术，可以了解操作流程
4. 分析师融入工作环境去观察实际工作任务，深入了解，发掘隐藏需求

利于发现以下两种需求：

1. Requirements that are derived from the way in which people actually work, rather than the way in which process definitions say they ought to work
2. Requirements that are derived from cooperation and awareness of other people’s activities.

缺点，由于过分聚焦于终端用户：

1. 不适用于发现组织或domain requirements
2. 不能确保识别出应当添加到系统中的功能

REQUIREMENTS VALIDATION需求验证

定义：检查需求是否是客户实际想要的
重要性：开发过程中或结束后才发现需求文档中的错误会增加工作量

different types of checks：

1. Validity checks有效性检查 - The functions proposed by stakeholders should be aligned with what the system needs to perform. You may find later that there are additional or different functions are required instead.
2. Consistency checks一致性检查 - Requirements in the document should not conflict. That is, there should not be contradictory constraints or different descriptions of the same system function.
3. Completeness checks完整性检查 - The requirements document should include requirements that define all functions and the constraints intended by the system user.
4. Realism checks可用性检查 - Using knowledge of existing technology, the requirements should be checked to ensure that they can actually be implemented.
5. Verifiability可验证性 - To reduce the potential for dispute between customer and contractor, system requirements should always be written so that they are verifiable.

requirements validation techniques：

1. Requirements reviews 需求采访 - The requirements are analyzed systematically by a team of reviewers who check for errors and inconsistencies.
2. Prototyping 原型机 - In this approach to validation, an executable model of the system in question is demonstrated to end-users and customers
3. Test-case generation测试 - Requirements should be testable. If the tests for the requirements are devised as part of the validation process, this often reveals requirements problems.

week5

Characteristics of a software engineer：

1. Master the technical stuff
2. learn and apply the skills required to understand the problem
3. design an effective solution
4. build the software
5. test it to develop the highest quality possible
6. Manage change
7. communicate with stakeholders
8. use appropriate tools in the appropriate situations

seven traits of effective software engineer

1. sense of individual responsibility
2. has an acute awareness of the needs of others
3. honest and brave to face the truth
4. exhibits resilience under pressure
5. has a heightened sense of fairness
6. exhibits attention to detail
7. pragmatic.

好的团队(team)需要做到1+1>2的效果( the whole is greater than the sum of the parts)

The jelled team

• establish a sense of purpose
• inculcate a sense of involvement that allows every member to feel that his skillset and contributions are valued
• foster a sense of trust
• encourage a sense of improvement
• diverse in the sense that they combine a variety of different skill sets

Software Engineering KNOWLEDGE

三年期限: 今天所用到的软件开发知识会在三年后被别的东西替代，
然而，有些根本的基础的知识将会伴随一生
These software engineering principles are likely to serve a professional programmer throughout his or her career.

以下准则可以帮助指引开发软件过程(software process) is which provides software engineer a road map for getting to a successful destination） 开发方向

• Be agile
• Focus on quality at every step
• Be ready to adapt
• Build an effective team
• Establish mechanisms for communication and coordination
• Manage change
• Assess risk
• Create products that provide value for others

以下准则可以帮助指引开发实践(software engineering practice) is which provides software engineer with the detail you’ll need to drive along the road. 开发方法

• Divide and conquer
• Understand the use of abstraction
• Strive for consistency
• Focus on the transfer of information
• Build software that exhibits effective modularity
• Look for patterns
• When possible, represent the problem and its solution from a number of different perspectives
• Remember that someone will maintain the software

以下准则可以帮助交流( activities comunication) is which a kind of comunication before requirements is specified.

•Listen
•Prepare before you communicate
•Someone should facilitate the activity
•Face-to-face communication is best
•Take notes and document decisions
•Strive for collaboration
•Stay focus; modularizes your discussion
•Use drawing whenever something is unclear
•Move on
•Negotiation is not a contest or a game. It works best when both parties win

以下准则可以帮助规划( activities planning) is which can enable the software team to define a road map as it travels toward its strategic goal and tactical objectives

• Understand the scope of the project
• Involve stakeholders in the planning activity
• Recognize that planning is iterative
• Estimate based on what you know
• Consider risk as you define your plan
• Be realistic
• Adjust granularity as you define the plan
• Define how you intend to ensure quality
• Describe how you intend to accommodate change
• Track the plan frequently and adjust as required.

week6 System Modeling

本节需要区分UML图类型diagram和系统模型类型model

什么是System Modeling：
System modeling is the process of developing abstract models of a system, by using some kind of graphical notation，with each model presenting a different view or perspective of that system.System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.
是一种讨论系统的手段，使用部分图像。可以作为系统的大概讨论，亦或是对现有系统的文档支持，也可作为详细的系统描述以支持系统实现。可以帮助分析师和客户了解系统。

1. Models of the existing system: 通过在需求分析中使用模型，可以帮助识别现有系统的功能，为评估现有系统的强弱提供帮助，进而为新系统提供建议
2. Models of the new system：通过在需求分析中使用模型，可以帮助向甲方解释需求，工程师使用这些模型讨论设计目的和完成系统文档。

System perspectives
external perspective	the context or environment of the system
interaction perspective	interactions between a system and its environment, or between the components of a system.
structural perspective	organization of a system or the structure of the data that is processed by the system
behavioral perspective	the dynamic behavior of the system and how it responds to events

UML diagram types
Activity diagrams	the activities involved in a process or in data processing
Use case diagrams	w the interactions between a system and its environment
Sequence diagrams	interactions between actors and the system and between system components
Class diagrams	the object classes in the system and the associations between these classes
State machine diagrams	how the system reacts to internal and external events

System Modeling分类和模型驱动：

• Context models
• Interaction models
• Structural models
• Behavioral models
• Model-driven engineering

Context models

作用：显示系统边界之外的内容。Architectural models决定了系统和其他系统的关系。
受影响：社会和组织关注会决定系统边界(system boundaries)。
注意：只是显示环境中的其他系统，无关于如何使用正在开发的系统。可以与其他模型一起使用。使用UML activity diagrams定义business process models

1. 系统边界：定义了什么在系统内部，什么在系统外部，展示了与这个系统有关的其他系统。对系统需求有影响，一定程度上决定了工作量

Interaction models

作用：给用户交互做模型，可帮助分析用户需求。给系统间交互做模型，可以注意交互问题。给组件交互做模型，可以帮助人们理解目标系统是否具有需求的功能和可靠性。
注意：使用UML 的 Use case diagrams and Sequence diagrams

1. Use case diagram：最初是为了需求获取，现在整合进了UML，每个用例代表一个设计系统外部交互的离散的任务(discrete task)。参与者可能是人或系统。使用图表和更详细的文本表现
2. Sequence diagrams：UML的一部分，用于按照现后序列表示actors和object的交互，对象在顶部，从中垂直绘制虚线，交互由带注释的箭头表示。

Structural models

作用：在讨论和设计系统体系结构时创建结构模型。显示组成一个系统的组成部分和其关系。可以看作一个静态模型，展现了系统设计，也可看作一个动态模型，展现了系统运行时的组成。
注意：使用UML Class diagrams

1. Class diagrams：用于面向对象的系统模型，显示系统中的类以及这些类之间的关联。类可以看作是对一种系统对象的大概定义。在早期开发阶段，对象表示现实世界的某些角色或物品。
   

Behavioral models

作用：显示系统运作时的动态表现，展现了当系统响应刺激(stimulus)后正在发生什么或期望发生什么。
影响：这些可被响应的刺激包含 数据 和 事件。
注意：许多商业系统是数据驱动系统(data-processing systems)，他们由数据驱动，数据输入控制系统功能，只涉及一小部分外部事件。

1. Data-driven models：Data-driven models展示了对数据操作的顺序。在需求分析期间用于显示系统的端到端处理。
   
2. Event-driven modeling：实时系统通常是事件驱动的，设计少量数据处理，显示系统如何相应外部和内部事件，主要涉及系统的状态转移。For example, a system controlling a valve may move from a state ‘Valve open’ to a state ‘Valve closed’ when an operator command (the stimulus) is received
3. State machine diagram：模拟了系统响应外部和内部事件的行为，显示了系统对刺激的响应，用于实时系统建模。节点为状态，事件为状态间的弧。常用于表示state machine models。
   
   
   由于状态众多，可以隐藏一些细节
   

Model-driven engineering

是什么：MDE是一种软件开发方法，其中主要输出是模型，从模型中自动实现在软硬件平台上运行的程序，这种行为将软件工程抽象，工程师无需关系编程语言的细节。
优点：允许系统高度抽象，自动实现代码意味着移植到其他系统的成本低
缺点：抽象系统不一定容易实现，新平台开发翻译器的成本或许超过写代码的成本

其前身是Model-driven architecture (MDA)，以模型为中心的软件开发方法，使用UML模型的子集描述系统。创建不同抽象级别的模型，从一个高级抽象的模型中原则上可以自动生成一个工作程序

模型种类

1. A computation independent model (CIM)
   These model the important domain abstractions used in a system. CIMs are sometimes called domain models.
2. A platform independent model (PIM)
   These model the operation of the system without reference to its implementation. The PIM is usually described using UMLmodels that show the static system structure and how it responds to external and internal events.
3. Platform specific models (PSM)
   These are transformations of the platform-independent model with a separate PSM for each application platform. In principle, there may be layers of PSM, with each layer adding some platform-specific detail.

MDA和Agile methods：

MDA支持迭代开发因此可以敏捷开发，但前期广泛建模和敏捷宣言思想矛盾。如果代码转换可以完全自动，并且从PIM可生成完整的程序，原则上MDA可用于敏捷开发。

要让代码可以完全自动，可以使用UML 2/xUML/Executable UML
模型类型被减少为：

1. Domain models that identify the principal concerns in a system. They are defined using UML class diagrams and include objects, attributes and associations.
2. Class models in which classes are defined, along with their attributes and operations.
3. State models in which a state diagram is associated with each class and is used to describe the life cycle of the class.

系统的动态行为可以使用 object constraint language (OCL)或 UML’s action language

week8

Class-based Model

Identify, classify, and define objects, ideas, and events as Classes by examining the usage scenarios developed in the use case model
将usage scenario里面的关键词分类，以创造一个具有候选类的表格，然后分析是否应该pass以创建一个类去存储与其相关的信息

• What to look for exactly?
• External entities
• Things
• Occurrences or events
• Roles
• Organizational units
• Places
• Structures

Use six selection characteristics to select classes for
the analysis model: -
• Retained information
• Needed services
• Multiple attributes
• Common attributes
• Common operations
• Essential requirements

Class Attribute 类属性:
属性用来描述一个类。
分析scenario来选择属于某个类的属性
eg. • Master password • Telephone number • Delay time

Class operations 类操作：
操作定义了一个类的行为，4种类型：
• manipulate data
• Perform computation
• Inquire about the state of an object
• Monitor an object for the occurrence of event
操作作用于类的属性和类之间的关系
分析scenario中的动词来发现对于类的操作，有的动词可能包含多个操作的集合
eg PC is used to program and configure the system

Associations between Classes类之间的关联：
关联是两个类之间的关系
eg Employee class is associated to Department, Attendance, and Project
关联可以进一步表示多样性（ multiplicity），既实例之间的关系数
eg Each Employee reports to one and only one Department

例题：PPT的链接

Behavior-based Model

表现系统的动态行为 (特定事件，系统如何响应）

如何创建Behavior-based Model

1. evaluate all use cases to fully understand the sequence of interaction within the system,
2. identify events that drive the interaction sequence and understand how these events relate to specific objects,
3. create a sequence for each use case,
4. build a state diagram for the system,
5. review the behavioral model to verify accuracy and consistency.

如何识别事件
actor和system之间进行信息交换，信息交换是一个事件，并且可能会影响控制流

什么是Event：
是某一个时间点发生的离散信号，硬件中断或消息传递。
可能导致：状态变化，触发操作，触发条件

State of a Class：
A passive state is simply the current status of all of an object’s attributes，如学生姓名，学生ID这类属性的当前状态
The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing，如学生Class的状态：新的，注册的，停学的，毕业的 等经历持续地转变或处理的当前状态

Event and State：
• An event (sometimes called a trigger ) must occur to force an object to make a transition from one active state to another.

接下来讨论State Machine Diagram（维护class根据evernt后改变state) 和 Sequence Diagram (维护软件在时间线上的行为）

State Machine Diagram

UML state machine diagram documents these kinds of changes of Objects‘ states after response to
events.
• It presents the states an object can be in along with the transitions between the states
• It shows the starting point and endpoint of a sequence of state change

3 categories of activities

1. entry / actionn: discrete action, perform only once at the entrance to the state
2. do / activity: continuous activity throughout the state live span
3. exit / action:n: discrete action, perform only once at the exit of the state

Sequence Diagram

什么是序列图：

1. indicates how events cause transitions from between key objects
2. representation of how events cause flow from one object to another as a function of time.
3. Once events and objects have been identified by examining a use case, the modeler creates a sequence diagram
   

例题PPT链接

week9 软件设计

突发恶疾拖了一周

**The goal of design:**软件设计目的
to produce a model or representation that exhibits:

• Firmness (no bugs)
• Commodity (useful or valuable)
• Delight (pleasurable experience)

什么是软件设计：
软件设计将需求转化为适合程序员进行软件编码和实现的形式
软件设计是建模modelling活动中的最后一步，这一步为construction构建代码提供台阶 (也就是说它夹在需求概念和代码实现中间，为需求提供解决方案solution space。

Analysis vs Design：
分析：identifies ’what’ the system must do 定义了系统应当具备或实现怎样的功能 (指明方向
设计：specifies ’how’ it will do it 概念上指定系统将通过何种手段实现这些功能 (并不是完整代码
面对对象分析object-oriented analysis：着重于发现用例里的实例，如图书，管理者
面对对象设计object-oriented design：着重于定义软件对象以及如何协调工作。如图书对象的title属性和管理者的findTtile()方法.

需求模型转换为设计模型：

以骰子游戏为例阐述分析和设计：
DICE GAME：
in which a player rolls two dice. If the total is seven, they win; otherwise, they lose.
见ppt 17-25

Design modeling

represents the features of the software that helps engineer to develop it effectively. (methods for software design)，classified into four categories：

• Data design/class design
• architectural design
• interface design
• component-level design

评估软件设计的质量：
Design quality is all about fitness to purpose (goal of design)

• does it do what is needed?
• does it do it in the way users need it to?
• does it do it reliably enough? fast enough?
• will it be affordable? will it be ready when its users need it?
• can it be changed as the needs change
  还是要考虑软件和运行环境的关联，不同环境下运行环境

Four key quality concepts:

• Reliability
• • designer must be able to predict how the system will behave:
• • • completeness - does it do everything it is supposed to do (e.g. handle
      all possible inputs)
• • • consistency - does it always behave as expected? (e.g. repeatability)
• • • robustness - does it behave well under abnormal conditions? (e.g.
      resource failure)
• Efficiency
• • Use of resources such as processor time, memory, network bandwidth
• • • This is less important than reliability in most cases
• Maintainability
• • How easy will it be to modify in the future?
• Usability
• • How easy is it to use?

另一种评估标准：

软件设计的目的：

1. 提供给软件设计者一个可拓展的基础形式a foundation form
2. 设计一个可拆分为组件的标准 can be used to partition software into individual
   component
3. 建立软件设计的统一标准 uniform criteria

软件设计的一般概念：

1. Abstraction 抽象
2. Modularity 模块化
3. Coupling 耦合
4. Cohesion 内聚
5. Object-oriented design 面向对象设计

Abstraction 抽象

只关注重要的部分，而舍弃细节，降低整个设计的复杂性
抽象层次越高，细节就越少。

1. 程序抽象：注重关键的方法
2. 数据抽象：注重关键的数据

Modularity 模块化

Modular design helps us to better organize complex system. It basically clusters similar or relative functions together, sets up boundaries and provides interfaces for communication
模块化设计帮助我们更好地组织复杂系统。它将相似或相对的功能聚集在一起，作为一个模块化的复杂系统，为模块间交流提供接口

Coupling and cohesion are two modularization criteria, which are often used together.
耦合和内聚是评判模块化的标准，尽可能做到低耦合，高内聚

模块数量的过多会带来成本的增加

Coupling 耦合

指模块的独立程度 （ how depend a class or a module is）
Two modules are considered independent if one can function completely without the presence of the other, they two are solvable and modifiable separately

The more connections between modules, the more dependent they are

1. “Highly coupled” : modules have strong interconnections
2. “loosely coupled”: modules have weak interconnections
   模块间越松散,接口越少，接口复杂性越低，越容易对功能进行修改

to lower the coupling between modules is to strengthen the bond between elements of the same module by maximizing the relationship between elements of the same module ↓↓↓

Cohesion 内聚

指模块内的元素间的相互关联的程度 (how focused a class or a module is)
Cohesion is the degree of how closely the elements of a module are related to each other

可以为设计者提供参考，”当前模块里的东西之间是不是毫不相关，是不是可以分成两个模块“

1. Method cohesion：方法内的变量与实现方法的目的强相关，这个方法的目的应当明确
2. Class cohesion：实现抽象类中类的元素与类的概念强相关，如果这个类中可以分成两个类（低内聚），那么就应该把他分成两个类
3. Inheritance cohesion：实现继承过程中提高了可重用性reusability但是降低了内聚性–了解一个类的所有功能还需要顺带检查它的父类

Object-oriented design 面向对象设计

An object-oriented system is made up of interacting objects
interacting objects maintain their own local state and provide operations on that state.

需要设计：存在哪些对象，对象间的关系如何

To develop an object-oriented design from concept to detailed, here are several things that you need to do:

• Understand and define the context and the external interactions with the system.
• Design the system architecture.
• Identify the principal objects in the system.
• Develop design models
• Specify interfaces

week10 Architectual Design

大概讲了软件架构Software Architecture，
软件架构设计Architectural Design，
软件架构模型Architecture Model(UML)，
软件架构视图Architectural Views，
软件架构模式Architectural Patterns

什么是Software Architecture：
The software architecture of a system is the set of structures(比如models) needed to reason about the system, which comprises software elements, relations among them, and properties of both.

什么是Architecture Model：
Architecture Model是整个复杂软件系统的简单概括，需要考虑整个系统各个环节上的failure risk，进而提出解决方案–The model helps you reason about and avoid failures, the details included in your model is architectural

Failure risks→Architectural details

什么是Architectural Design：
Architectural Design is the design process for identifying the sub-systems making up a system and the framework for sub-system control and communication.
架构设计会产出一个软件架构的描述

架构设计处于设计过程早期阶段，通常与一些规范活动(specification activities)同时进行，包括识别系统组件和组件间通信

软件架构中系统被拆分成子系统(系统组件)，并讨论他们之间的接口。
一个子系统应该高聚合Highly cohesive，低耦合Loosely coupled，提供一些主要服务，必要时还可以被拆成更小的子系统

子系统中的类class的选择：

1. 由地理关系决定分组(可能就是按文件分组)
2. 将同一个use case的类放一起
3. 考虑维护性，将需要一起维护的类放一起

软件架构被抽象的形式：

1. Architecture in the small，关注一个单独的程序如何被分解为组件

2. Architecture in the large，关注一个复杂的系统被分解为子系统，系统组件，分布式组件，甚至不同公司拥有的组件
   
   如何表示 Architectural：

3. 使用简单的方框图表示，这样甲方能看明白，不过会缺少细节。

4. 使用模型表示，不仅可以与甲方交流communication ，还利于项目规划project planning；还可以作为已有项目的记录，记录接口，连结，组件。

我们使用UML表示model，每个模型必须有个diagram和supporting specification，diagram会含有一些组件间关系，但并不具体

UML diagrams （systems architecture）

1. Package diagram
2. Component diagram
3. Deployment diagram

什么是component：
是系统中可更换的部分，代表比特数据，使用/开放了一系列接口，只有通过接口才能访问组件。拥有相同接口的组件可以更换。一个组件含有一个或多个class。组件可以组合成systems。
component can be thought of as an implementation of a subsystem

什么是class：
表示逻辑上的抽象。含有属性(data)和操作(methods)。类可以组合成programs。

A component diagram has a higher level of abstraction than a Class Diagram.
all of the model elements are private

什么是Package：
a package is a general-purpose mechanism for organizing elements into groups
形同java的jar包，用于打包各种class
package diagrams only display public items

什么是Deployment Diagram：
System’s physical layout: which piece of software run on which piece of hardware.
系统的物理上的布局

节点分为设备节点Device node(如电脑)和运行环境节点Execution environment node(如服务器)

什么是node：
A node is a physical element thar exists at run time and provides a computational resource, e.g., a computer, a smartphone, arouter.
Components may live on nodes

1. Node may have sub-nodes, appearing as nested box (e.g. DMBS running on a server)
2. Communication models by simple lines specifying the protocol used between nodes
3. Examples of artifacts are executable files, libraries, database schemas, configuration files, components, etc
4. Artifacts deployment shown by artifacts boxes within the node boxes.

Architectural Views

讨论使用哪些符号，使用哪些角度去形容架构模型。

架构模型没法面面俱到，每个架构模型只展示一种视角形容系统one view or perspective
of the system
It might show how a system is decomposed into modules, how the run-time processes interact or the different ways in which system components are distributed across a network. For both design and documentation, you usually need to present multiple views of the software architecture.

以下视角：

1. A logical view，描述系统如何架构，如何将功能分配给组件。
2. A process view，系统运行时的进程交互
3. A development view，软件是如何分解以发展的
4. A physical view，在哪些节点/计算机上部署哪些逻辑组件
5. Related using use cases or scenarios

Architectural patterns

An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments.
架构模式是对良好设计实践的风格化描述，它以前在不同的环境中进行过尝试和测试。
模式是用来表示知识的方法，架构模式可以解决各种软件工程中的问题

An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context
体系结构模式是在给定上下文中，针对软件体系结构中经常出现的问题的通用、可重用的解决方案

1. The Model-View-Controller (MVC) pattern
2. Layered pattern/Architecture
3. Repository pattern

The Model-View-Controller (MVC) pattern

用户接口user interface既要与功能性实现application相分离，两者又要互相影响。
底层实现更改时，用户接口需要created maintained and coordinated。

MVC可以作为许多基于网络的系统的交互管理的基础。

包含：

1. Model，管理应用程序的数据，逻辑
2. View，信息的输出表示
3. Controller，接受输入并将其转换成模型或视图的命令和实现视图和模型之间的互连
   
   优点：将数据与显示分离，允许以不同的方式展现同一数据。
   缺点：提高代码复杂度

Layered pattern/Architecture

is used to model the interfacing of sub-systems

Organises the system into a set of layers (or abstract machines) each of which provide a set of services. Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected.
将系统组织成不同的层，每个层提供一组服务。支持不同层中子系统的增量开发，当层界面发生更改时，仅相邻层受到影响

每个底层可以被多个高层所使用
分层可以用于构建一般桌面应用程序和简单的Web应用程序，又或是需要快速开发得到成品的情况。
在高性能应用程序中性能很差，通过多个层来满足业务请求效率不高。

优点：允许更换每个层，每个层的功能可以丰富扩充
缺点：实现层之间纯净的分离很困难，高级别层可能必须直接与低级别的层交互，导致层之间并不是链式结构。性能堪忧–处理响应时每一层都要做解释

Repository pattern

仓库：使用单独的仓库存储数据

优点：对于数据密集系统十分灵活
缺点：难于改变仓库，因为所有其他组件都依赖它

仓库结合存储访问层：
优点：只要接口不变，仓库内的功能可以随便改变

例子：

week11 Component-Level Design

A comple set of software components is defined during architectural design. But the internal data structures and processing details of each component are not represented at a level of abstraction that is close to code
软件架构设计后的软件组件的抽象层次还需要再往代码层面靠一靠。

Component-level design

what component level design do:

• Component-level design defines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each software component.
  组件级别设计以代码或图表的形式定义了每个软件组件的数据结构，算法，接口和交流机制。

three different view of a component:

• An object-oriented view
• A conventional view
• A process view

An object-oriented view面向对象视角

以面向对象视角来看，组件是一组互相协作的类collaborating classes。每个类中包含与其实现相关的所有属性和操作，以及与其他类通信和协作的接口。

A conventional/traditional view

传统视角来看，组件是程序的功能元素functional element，包含：

1. processing logic 处理逻辑
2. internal data structure 内部数据结构，用于实现处理逻辑
3. interface 接口，用于数据的传入传出

A process view

1. building a system from existing components rather than creating each component from scratch.从现有组件中构建系统
2. with developing, you choose components or design patterns from the catalog and use them to populate the architecture.随着开发，可以从目录中选择组件或设计模式填充体系结构

component-level design process steps:

1. Identify all design classes that correspond to the problem domain.
2. Identify all design classes that correspond to the infrastructure domain. 指GUI组件，操作系统组件，数据库组件
3. Elaborate all design classes that are not acquired as reusable components. 详细描述实现类所需的所有接口，属性和操作。考虑聚合和耦合。
   1. Specify message details when classes or components collaborate.消息协议
   2. Identify appropriate interfaces for each component. 每个组件的接口
   3. Elaborate attributes and define data types and data structures required to implement them定义属性所需数据类型和数据结构
   4. Describe processing flow within each operation in detail 使用伪代码或活动图来描述单个目标功能之间的流程
4. . Describe persistent data sources (databases and files) and identify the classes required to manage them. 描述持久数据库并确定管理它们的类
5. Develop and elaborate behavioral representations for a class or component.为类或组件开发和细化行为表示
6. Elaborate deployment diagrams to provide additional implementation detail.指定将使用的特殊硬件和操作系统环境。
7. Refactor every component-level design representation and always consider alternatives.重构每个组件，考虑备选方案。

Design and Implementation

设计和实现是软件工程中开发可执行软件的阶段。
结构化面向对象设计过程中涉及到开发许多不同的系统模型system models。
对于由不同团队开发的大型系统，设计模型是一种重要的通信机制。
这些过程包括：

1. Define the context and the external interactions with the system
   这对于决定如何提供所需的系统功能以及如何构建系统以与其环境通信至关重要
   -system context是一种结构模型，用于演示正在开发的系统环境中的其他系统。
   -interaction model是一个动态模型（use case+结构化自然语言描述），显示系统如何与其环境交互
2. Design the system architecture
   确定组成系统的主要组件及其交互，使用体系结构模式architectural pattern（分层或客户-服务器模型）
3. Identify the principal system objects
4. Develop design models
   design models显示对象和对象类以及这些实体之间的关系
5. Specify object interfaces

Sequence models

Sequence models show the sequence of object interactions. These are represented using a UML sequence or a collaboration diagram. Sequence models are dynamic models.

State machine models

State machine models show how individual objects change their state in response to events. These are represented in the UML using state diagrams. State diagrams are useful high-level models of a system or an object’s run-time behavior.

以上无关编程，程序写代码过程中中还需要关心：

1. Reuse现在大多数软件都是重用已有代码
2. Configuration management管理软件的许多不同版本
3. Host-target development测试机与开发机不同
4. Open source development开源开发

week12 Interface Design

User interface design creates an effective communication medium between a human and a computer.

The golden rules

1. Place the user in control
   应当只提供给用户最必要的默认互动，并提供灵活的交互。
   用户操作应当可保存性的中断和取消（ interruptible and undoable）。
   用户应当可与肉眼可见的元素互动。
   显示系统的状态
2. Reduce the user’s memery load
   减少对短期内存的需求，接口设计应减少存储过去的动作，输入，结果和输出。
   使用有意义的默认值，用户应当注意的地方不应该设置默认值（这个不应该算在第一点里吗。。。
   减少使用业内术语，使用易于阅读的语言
   界面的视觉布局应基于现实世界隐喻(real-world metaphor)，加强虚拟与现实之间的联系。
3. Make the interface consistent
   页面之间所有视觉元素布局应当一致。

用户界面的分析和设计过程是迭代的，可以使用螺旋模型（spiral model）表示

通常使用文档来细化一个用户界面是很难的，界面的需求来自于与现有系统的比较，界面的设计设计许多原型机

一个软件工程模型的关键原则：
在设计解决方法前深入理解问题

User Analysis

用户接口设计需要理解：

1. The people (end-users) who will interact with the system through the interface;
2. The tasks that end-users must perform to do their work,
3. The content that is presented as part of the interface,
4. The environment in which these tasks will be conducted

如何改进用户接口：

1. 用户访谈，软件团队和用户交流了解他们的需求，动机，工作文化和大量其他问题。
2. 销售投入：销售人员和用户，客户交流，了解需求
3. 营销投入：市场分析，提供对每个细分市场对软件使用的理解
4. 支持投入：支持人员（维护人员）与用户交谈，了解喜欢和不喜欢什么。

Task Analysis

任务分析将分析任务的内容，开始和结束时间，任务过程中用户将处理哪些问题，任务的先后顺序和任务的层次。

Once user tasks have been identified, user scenarios (use cases) are created and analyzed to define a set of interface objects and actions.

User Interface Design Patterns

Patterns: 指表达知识的方式
Architectural pattern: 被测试和检验过许多次的design practice
Design pattern: 一种抽象的对某种方法的设计解决方案

User Interface Design Issues

1. Response time
   Length：响应时间，Variability：每次响应之间的差别
2. Help facilities
   提供尽可能的响应菜单
3. Error handling
   产生的错误消息应该使用用户能够理解的术语描述问题，提供解决建议，说明错误结果
4. Application accessibility
   良好的使用感受，照顾特殊人群
5. Internationalization
   国际化。

Design Ecaluation

创造原型机后，应该被使用者评估是否达到需求

什么时候测试：
迭代开发时，产品上架前，产品登陆后

如何衡量usability：
Effectiveness，Efficiency，Satisfaction。

测试过程：

1. Preparation
   测试目标，用户任务，招募参与者
2. Sessions
   使用Lab，模拟工作环境，观察操作者操作
3. Results Analysis
   测试系统，而不是使用者，不要强迫用户改变潜意识行为。

week13 Software Validation软件验证

软件验证之后是软件演化(software evolution),软件演化包含软件发布后的持续开发，本课程不包括这点。

什么是软件验证software validation：
分为verification 和 validation，需要保证：

• 系统符合其规范specification
• 系统满足客户的期望

Verification和validation的区别：

Verification （It consists of checking of documents/files and is performed by human.
软件是否做了它被定义了要去做的

It is the process of checking that a software achieves its goal without any bugs.
It is the process to ensure whether the product that is developed is right or not.
It verifies whether the developed product fulfills the requirements that we have.
It is part of the software development process that ensures the work is correct.

Validation （It consists of execution of program and is performed by computer.
软件是否做的是对的事情

It is the process of checking whether the software product is up to the mark or in other words product has high level requirements.
It is the process of checking the validation of product i.e. it checks what we are developing is the right product.

V&V的目标是确认系统是否符合目的：

1. 软件目的
2. 用户期望
3. 市场环境

什么是Program Testing：
测试环节使用测试数据和环境进行程序测试，其目的是确保一个程序做了它要做的事情，并且没有缺陷或异常。其目的：

1. 向开发人员和客户证明软件达到要求。如实现了一个或组合的功能
2. 发现软件不正确的错误行为，或不符合规范的情况。如系统崩溃和数据损坏。

Validation and detect testing：

1. validation testing：向系统输入测试数据，它做了系统应当实现的功能。
2. defect testing：缺陷测试能够暴露意外情况或非正常输入操作下系统的错误处理能力。
   (虽然这么说，但这不就是把上面两点换个角度说一遍吗。。。）

An input-output model of program testing:

Validation testing: 验证测试包括使用Ie之外的正确输入进行测试。这些输入刺激系统生成预期的正确输出。
detect testing：缺陷测试缺陷测试的首要任务是在Ie集合中找到这些输入，因为这些输入揭示了系统的问题。

Stages of testing:

1. Development testing

• unit testing: focus on objects or methods
  it is a defect testing process. Unit tests hellp with code re-use.
  unit test可以使用自动化调试框架（分为setup,call,assertion三个子环节)自动化测试可以测试正常操作的合理进行和异常操作的应对。
• component testing: focus on testing component interfaces
  Component testing is performed by testers.
  Testing composite components should therefore focus on showing that the component interface behaves according to its specification.
• system testing: focus on testing component interactions
  The focus is testing the interactions between components.
  System testing tests the emergent behaviour of a system.
  Components developed by different team members or sub-teams may be integrated at this stage. System testing is a collective rather than an individual process.
• Use-case testing
  The use-cases developed to identify system interactions can be used as a basis for system testing.
• Integration testing
  集成测试注重于接口间的交互，而不关心组件内操作

2. Release testing
   Release testing is the process of testing a particular release of a system that is intended for use outside of the development team. 是另一种形式的system testing

Requirement based testing：使用一个或多个测试用例测试每个需求
Performance testing：逐渐增加系统负载，直到超出系统承受能力。超出承受能力这部分又被称为压力测试(Stress testing).

3. User testing
   User or customer testing is a stage in the testing process in which users or customers provide input and advice on system testing.

Alpha testing：Users of the software work with the development team to test the software at the developer’s site. 闭测
Beta testing：A release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers.公测
Acceptance testing：Customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment. Primarily for custom systems.

Appendix：
Black box testing
a software testing method in which the internal structure/ design/ implementation of the item being tested is not known to the tester.
The testing is done without the internal knowledge of the products.
From ‘outside’, just the public method

White box testing
analyze the internal structures the used data structures, internal design, code structure and the working of the software rather than just the functionality as in black box testing.
From ‘inside’, considering all aspect (including private methods and feilds)