CPT203-Software Engineering 笔记

Week 1 -- Introduction

failure reason 

professional software development***

maintain, security, efficiency, acceptability

two kinds***: generic, customized

software deterioration 软件退化

reduce changes/ side effects after changes

software engineering approaches 软件工程方法***

4 fundamental activities:s,d,v,e(迭代优化) Lec1 p24

•软件规范（Software specification）（需求明确）

•软件开发（Software development）

•软件验证（Software validation）

•软件进化（Software evolution）（软件迭代）

开发方法

• 顺序开发（Sequential）
• 迭代开发（Iterative）

ethics***

软件开发的风险（SOFTWARE DEVELOPMENT RISK） 风险***

minimize risks -- communicate

Week 2 --software process

a set of related activities

•软件规范（Software specification）
•软件设计和实现（Software design and implementation）
•软件验证（Software validation）
•软件进化（Software evolution）

classification***

plan driven/ agile process

process models 软件过程模型 p12

•瀑布模型（The waterfall model）

This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing, and so on.

*document produced in each stage

* free parts 

 原则上，瀑布模型应该只在需求被很好地理解并且在系统开发期间不太可能发生根本变化的情况下使用

•增量开发（Incremental development）

This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.

优点：

成本低，快速，客户及时反馈

缺点：

•进程不可见。

•随着新增量的增加，系统结构趋于退化（错误越来越多）。

•面向重用的软件工程（Reuse-oriented software engineering）

This approach is based on the existence of a significant number of reusable components. The system development process focuses on integrating these components into a system rather than developing them from scratch.

注意：这些模型不是相互排斥（mutually exclusive）的，并且经常一起使用，特别是对于大型系统开发。

e.g web服务， 包，standalone software

优点：

less work/cost/risks

faster

缺点

· 然而，需求妥协（requirements compromises）是不可避免的，这可能导致系统不能满足用户的真正需求。

• 此外，由于可重用组件的新版本不在使用它们的组织的控制之下，因此失去了对系统演化的一些控制（新版本上线，有些东西不能用了）

SOFTWARE PROCESS ACTIVITIES 软件过程活动

定义***现实的软件过程是技术、协作和管理活动的交错序列，其总体目标是指定、设计、实现和测试软件系统（specifying, designing, implementing, and testing a software system）

•在瀑布模型中，它们按顺序组织（in sequence）

•在增量开发中，它们是交错的（interleaved)

SOFTWARE SPECIFICATION

requirement engineering

- 2level high level/ detailed level 

-4 activities p35 

需求工程过程的目的是产生一个商定的需求文档，该文档指定了一个满足涉众需求的系统。

SOFTWARE DESIGN AND IMPLEMENTATION 软件设计和实现

•软件开发的实现阶段是将系统规范转换为可执行系统的过程。

•它总是涉及软件设计和编程过程，但是，如果使用增量开发方法，也可能涉及软件规范的细化（refinement of the software specification）。

•软件设计是对要实现的软件结构、系统使用的数据模型和结构、系统组件之间的接口，有时还包括所使用的算法的描述。
*迭代设计

输入：平台信息。需求规范说明，数据描述

输出：软件结构，数据库规范描述，接口规范描述，组件规范描述

design activity 设计活动

体系结构设计（Architectural design）

接口设计（Interface design）

组件设计（Component design）

数据库设计（Database design）

Software Validation 软件验证

•    a system both conforms to its specification
•    it meets the expectations of the system customer

Validation techniques 验证技术

三个阶段的测试过程包括对系统组件的测试(testing for system component)，然后是对集成系统的测试( testing for an integrated system)，最后是使用客户数据对系统进行测试(testing of the system with the customer’s data)

开发测试(Development testing)

组件测试,独立

系统测试（System testing）

组件交互

验收测试（Acceptance testing）

用户数据

Week 3 -- Agile methods

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: interleaved， Minimum documentation，series of version with system stakeholders involvement， interactive development system

Principle

•    Individuals and interactions over processes and tools
•    Working software over comprehensive documentation
•    Customer collaboration over contract negotiation
•    Responding to change over following a plan

Challenge

- require: a customer who is willing and able to spend time with the development team and who can represent all system stakeholders

- Individual team members may not have suitable personalities for the intense involvement

- Prioritizing changes difficult

- contract difficult - time paid

- responsibility 

-maintain continuity

Maintenance 维护

正式的文档应该能简化系统的演化和维护。然而，在实践中，正式文档通常是不更新的，在系统可维护性方面也是如此（对文档的不重视性可能导致维护性差）

system requirements document **

Plan-driven and Agile development 计划驱动和敏捷开发

10个问题

•    Detail specification and design needed?
•    Is incremental strategy realistic?
•    How large is the system?
•    What type of system being developed?
•    System life span?

•    Available technologies and tools?
•    Organization of the team?
•    Cultural issues?
•    Available skillsets?
•    External regulation?

Week 4 -- Requirement Engineering

是software specification这个阶段的任务哦！

高层描述（high-level description）User requirements；
细节描述（detail description）System requirements

Functional  requirement

· 功能需求

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.

完整性(Completeness)，一致性(Consistency)

类型：

通用性需求；状态驱动的需求；事件驱动的需求；可选功能需求；异常行为需求；复杂需求

Non-functional requirement*****

· 非功能需求

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. 

系统属性（System properties）

重要：如可靠性、安全性和机密性需求（reliability, safety, and confidentiality）

1. failing the unfunctional requirement means the whole system is unuseable

2. affect overall architecture

3 may generate a number of related functional requirements

非功能分类↓

•    Product requirements - These requirements specify or constrain the behavior of the software.
•    Organizational requirements - These requirements are broad system requirements derived from policies and procedures in the customer’s and developer’s organization.
•    External requirements - This broad heading covers all requirements that are derived from factors external to the system and its development process

定量地（quantitatively）

软件需求文档（The Software Requirements Document）

软件需求文档(有时称为软件需求说明书（software requirements specification）或SRS)是系统开发人员应该实现的正式文档。应该包括系统的用户需求和系统需求的详细规格说明

需求稳定的

质量特性：correct，complete，unambiguous，verificable， consistent， ranked for importance/stability, modifiable, traceable

需求工程过程（Requirements Engineering Processes）

和软件过程活动是一张图居然

4 high-level activities

-(可行性研究，feasibility study)

需求发现(获取和分析，elicitation and analysis),

转换成某种标准形式(规范，specification),

(验证，validation)

需求获取与分析（Requirements Elicitation and Analysis）

需求规范（Requirements specification）：需求被记录下来，并输入到螺旋的下一轮中。如第4.3节所述，可能会产生正式或非正式的需求文件

挑战 p39

1. unreachable

2. customer use their own terms

需求发现（Requirements discovery/elicitation）

This is the process of interacting with stakeholders of the system to discover their requirements

stakeholders--

interviews （close/open）a springboard question, a requirements proposal, a prototype system 来自访谈的信息补充了来自描述业务流程或现有系统的文档、用户观察等有关系统的其他信息。

observation

scenarios

prototypes

1.采访（Requirements Discovery - Interview）

2.场景（Requirements Discovery - Scenarios）

示例交互会话（example interaction sessions）,标识了系统与其用户或其他系统之间的单独交互

一般情况下，一个场景可能包括1.2.3.4.5

3.用例（Requirements Discovery - Use case）

4.人类学（Requirements Discovery – Ethnography）

站在需求方考虑，不是完整的启发（elicitation）的方法，用来填补其他方法

需求规范（Requirements Specification） p60

清晰的、无歧义的、容易理解的、完整的和一致的

在写用户的需求规范时，应1.2.3.4

1. 需求规范—自然语言规范（Natural Language Specification）

2. 结构化规范（Structured Specification）

结构化自然语言是一种使用自然语言在预定义的结构或模板中编写系统需求的方法

需求验证（Requirements Validation）

•Requirements validation is the process of checking that requirements correctly define the system that the customer really wants

types of checks

有效性检查（Validity checks）

一致性检查（Consistency checks）

完整性检查（Completeness checks）

真实性检查（Realism checks）

可验证性（Verifiability）

techniques

需求评审（Requirements reviews）

原型设计（Prototyping）

测试用例生成（Test-case generation）

重要性：不适当的 validation 可能导致rework

Week5 -- System Modeling

构成元素 elements

系统建模是开发系统抽象模型的过程，每个模型表示该系统的不同视图或视角

建模通过将复杂系统抽象成适当层次的细节来简化复杂系统

使用某种图形符号来表示系统，现在几乎总是基于统一建模语言(UML)中的符号

系统视角（System perspectives）

external/interaction/structural/behavioral  models

UML 图

这玩意我单独写一篇博客

活动图（Activity diagrams），显示流程或数据处理中涉及的活动。

用例图（Use case diagrams），显示系统与其环境之间的交互。

序列图（Sequence diagrams），显示参与者和系统之间以及系统组件之间的交互。

类图（Class diagrams），显示系统中的对象类和这些类之间的关联。

状态机图（State machine diagrams），显示系统如何对内部和外部事件作出反应。 

上下文建模（Context models）

illustrate the operational context of a system - they show what lies outside the system boundaries. 

social & organisational may affect System boundaries

1.生成一个简单的体系结构模型（a simple architectural model）

交互模型（Interaction models）

Modeling user interaction/system-to-system interaction/component interaction

用例图和顺序图（Use case diagrams and sequence diagrams）用于描述系统中用户和系统之间的交互（交互模型（Interaction models））。

用例图描述系统和外部参与者之间的交互;

序列图通过显示系统内部的对象之间的交互向这些图添加了更多的信息。

结构模型（Structural models）

static -- the structure of the system design

dynamic -- the organization of the system when it is executing

类图（class diagrams）用于定义系统中类的静态结构及其关联。

generalization 底层类是继承父类的属性和操作的子类,泛化显示为指向更通用类的箭头（三角箭头）

aggregation一个对象(整体)由其他对象(部分)组成,整体的类旁边使用一个菱形（菱形箭头）

行为模型（Behavioral models）

系统对来自环境的刺激(data/events)作出反应时发生了什么或应该发生什么

数据驱动模型（Data-driven modeling）

关于事件驱动的建模（Event-driven modeling）

活动图（Activity diagrams）和序列图可用于对数据处理建模（data-driven models），其中在活动图，每个活动表示一个过程步骤。

状态图（State diagrams）用于对系统响应内部或外部事件的行为进行建模（event-driven models）。

Week 8--Design Concepts

analysis 做什么

design 怎么做

analysis:  

goal

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

Design in the SE context

四个层次，由总到细，由高到低

Component level design

 transforms structural elements of the software architecture into a procedural description of software components.

Interface design

describes how the software communicates with systems that interoperate with it, and with humans who use it

Architectural design

defines the relationship between major structural elements of the software, the architectural styles and patterns that can be used to achieve the requirements defined for the system, and the constraints that affect the way in which architecture can be implemented.

data design/class design

transforms class models into design class realizations and the requisite data structure required to implement it.

Quality control in the design progress*

3 goals : satisfy implicit/explicit requirement/readable/complete picture

8 technical criteria p9 - architecture, modular, distinct representation, appropriate data structures, independent, repeatable, notation

Quality -- FURPS***

Functionality, Usability, Reliability, Performance, Supportability

Design concepts***

idea: foundation, partition, technical quality

Abstraction

Abstraction simply means to hide the details to reduce complexity and increases efficiency or quality.
procedural abstraction: a sequence of instructions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed.

data abstraction: a named collection of data that describes a data object.

Modularity

better organize complex system

Functional independence: coupling &cohesion

coupling: refers to the degree of interdependence between software modules

sol: interface--, cohesion++

cohesion: the degree of how closely the elements of a module are related to each other

object-oriented design

designing object classes

objects are created dynamically from these class definitions.

Elements in design model

Data

abstract → refined

Program-component level

Application level

Business level

Architectural

floor to the house

resources:

application domain

model elements

availability

Interface

doors and windows

UI, external, internal

Component-Level

detailed

UML-diagram

Deployment-Level

physical

Week 9--Architecture, Component-Level and Interface

Architecture Design

Architectural design is concerned with understanding how a system should be organized and designing the overall structure of that system. It identifies the main structural components in a system and the relationships between them. The output of this design process is a description of the software architecture.

affects: performance, robustness, distributability, and  maintainability

    Individual component – implement functional requirements
    System architecture – fulfill non-functional requirement

advance： stakehoder communication, system analysis, reuse

Architecture View

· Logical

shows the key abstractions in the system as objects or object classes.

· process

shows how, at run-time, the system is composed of interacting processes.

· development （模块）

shows how the software is decomposed for development.

· physical

shows the system hardware and how software components are distributed across the processors in the system.

scenarios：

用用例将另外几个视图串联

Aechitectural Patterns************

 Patterns are means of representing, sharing and reusing knowledge. A stylized description of good design practice,

· MVC （Model-View-Controller)

    Model: central component of the pattern that directly manages the data, logic and rules of the application
    View：can be any output representation of information, such as a chart or a diagram.
    Controller: accepts input and converts it to commands for the model or view, enables the interconnection between the views and the model

·  Layered Patterns

the system functionality is organized into separate layers, and each layer only relies on the facilities and services offered by the layer immediately beneath it.

supports the incremental development , not efficient 

· Repository Patterns

· Client-Server Patterns

· Pip and filter Patterns

Component-level Design

Component-level design occurs after the first iteration of architectural design has been completed.
 A complete set of software components is defined during architectural design.

define  data structures, algorithms, interface characteristics, and communication mechanisms

intermediate representations

➢    A software component is a modular building block for computer software.
➢    It can be used to review for correctness and consistency with other components.
 

Views of Component

·面向对象视角（object-oriented view）

Centers on objects as the fundamental building blocks of software. An object encapsulates both data and behavior, representing entities or concepts.

• 面向对象视图侧重于将系统建模为一组相互作用的对象，每个对象都封装了与在线购物相关的数据和行为。

· 传统视角（conventional view）

• 传统观点将系统构建为一系列执行特定任务的过程或功能，如添加产品、下订单和处理付款。

· 流程视角（process view）

• 流程视图根据系统的运行时行为来查看系统，特别是它如何处理订单和支付流，以及如何管理并发性和系统资源。

User Interface Design

golden rules

1. Place the User in control

 does not force

flexible interaction

interruptible and undoable

 direct interaction on screen

 visibility

2. Reduce the Users' Memory Load

Reduce demand on short-term memory.

default

realworld

3. make the interface consistant 

process

iterative

issues

Response time: length, variability

Help facilities

Error handling

Application accessibility

Internationalization

evaluation

Week 10--Software Testing

Testing basics

validation vs defect

validation testing 验证：

You expect the system to perform correctly using a given set oftest cases that reflect the system's expected use.

A successful test shows that the system operates as intended

defect testing 缺陷：

The test cases are designed to expose defects. The test cases indefect testing can be deliberately obscure and need not reflecthow the system is normally used

A successful test is a test that makes the system performincorrectly and so exposes a defect in the system.

verification vs validation

meeks specification and delivers functionality

verification: functional and non-functional requirements

validation: meets the customer's expectations

software inspections vs software testing

inspection : Concerned with analysis of the static system representation to discover problems(static V&V)

adavantage: ignore error interaction, no additional cost, border quality

testing : Concerned with exercising and observing product behavior (dynamic V&V)

stages of testing

Development testing

the system is tested during development to discover bugs and defects

Unit testing

where individual program units or object classes are tested. Unit testing should focus on testing the functionality of objects or methods.

unit : Object classes with several attributes and methods

automated test: setup, call, assertion

testing strategies

partition testing(类似的组合测试); single value, different size, boundaries, midpoint, zero length

guideline-based testing（容易出错地方的测试）

Component testing

several individual units are integrated to create composite components. Component testing should focus on testing component interfaces. * not individual components

interface testing 

interface misuse: A calling component calls another component and makes an error in its use of its interface e.g. parameters in the wrong order

interface misunderstanding: A calling component embeds assumptions about the behavior of the called component which are incorrect

timing errors: The called and the calling component operate at different speed sand out-of-date information is accessed

extreme ends, null pointers, component failure 

System testing

where some or all of the components in a system are integrated and the system is tested as a whole System testing should focus on testing component interactions

use-case testing

testing policies

Release testing

a separate testing team test a complete version of the system before it is released to users

system: bugs / release: check requirements

requirement based testing

scenario testing

performance testing - operational profile/ Stress testing

User testing

users or potential users of a system test the system in their own environment 

alpha - user and team at developer's site

beta - user experiment

acceptance-Customers 

Week 11--Junit Testing

JUnit

AssertTrue/AssertFalse

AssertSame/AssertNotSame

AssertEquals/AssertNotEquals

AssertArrayEquals

AssertThrows

life circle

@BeforeAll

@BeforeEach

@AfterAll

@AfterEach

@DisplayName

@Timeout

@RepeatedTest

Week12 Project Management

Challenges

intangible, one-off, variable and organization-specific

Risk management

•    Project risks: Risks that affect the project schedule or resources (e.g., loss of an experienced designer). 
•    Product risks: Risks that affect the quality or performance of the software being developed (e.g., failure of a purchased component to perform as expected). 

•    Business risks: Risks that affect the organization developing or procuring the software (e.g., a new product from competitors). 

阶段

•    Risk identification: identify possible project, product, and business risks

•    Risk analysis: assess the likelihood and consequences of these risks

probability

seriousness

•    Risk planning: plans to address the risk, either by avoiding it or minimizing its effects on the project

Avoidance strategies, Minimization strategies, Contingency plans

•    Risk monitoring: regularly assess the risk and your plans for risk mitigation and revise these when you learn more about the risk

managing people

4 critical factors: Consistency, Respect, Inclusion, Honesty

people type: Task/Self/Interaction-oriented people

Software team

a closed/random/open/synchronous paradigm

efficiency influence by: Group size/Group structure/Group composition/The physical work environment/ The available communication channels