软件过程

第二章、软件工程

1. Software Crisis

Software crisisis a term used in the early days ofcomputing sciencefor the difficulty of writing useful and efficient computer programs in the required time.软件危机就是早期软件工程很难在规定时间内完成有用、高效率的计算机系统。

2. 软件工程定义

Software Engineering:
(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).对1中方法的研究

3. A Layered Technology

• Quality Focus is a bedrock(根基) to support software engineering .软件的根基
• Process
• • Is the foundation of SW engineering to hold technology together to build software timely and rationally 软件的基本，集中技术来及时、明智地开发软件
• • Defines a framework for software development定义软件开发的框架
• • Forms a basis for software management control软件管理控制的基础
• Methods
• • Provide the technology : how to build software
• • Including many methods : communication, requirement analysis, design modeling, program construction, testing and support

• Tools
  Provides automated or semiautomated support for the process and the methods

  4. Software Process

  A process is a collection of activities, actions, and tasks that are performed when some work product is to be created.完成软件的一系列活动、步骤和任务

1. Process Framework

1. Framework activities
   are applicable to all software projects, regardless of their size and complexity.
2. Umbrella activities
   are applicable across the entire software process.

• Software project tracking and control软件工程追踪控制
• Risk management风险管理
• Software quality assurance质量保证
• Technical reviews技术审查
• Measurement衡量
• Software configuration management软件配置管理
• Reusability management复用管理
• Work product preparation and production工作生产准备和生产

2. Generic Framework Activities

• Communication
• Planning
• Modeling
• • Analysis of requirements
• • Design
• Construction
• • Code generation
• • Testing

• Deployment

  5. Hooker’s General Principles

1. The Reason It All Exists
2. KISS (Keep It Simple, Stupid!)
3. Maintain the Vision
4. What You Produce, Others Will Consume
5. Be Open to the Future
   
6. Plan Ahead for Reuse

7. Think!

   Summary

• Software engineering encompasses process, methods, and tools.
• The software process incorporates five framework activities:
• • communication,
• • planning,
• • modeling,
• • costruction and
• • deployment.

---

第三章、Software Process Structure

1. 过程定义

a process was defined as
a collection of work activities, actions, and tasks that are performed when some work products is to be created.

2. Process Flow

Process flow describes how the framework activities and the actions and the tasks that occur within each framework activity are organized with respect to sequence and time.
软件过程流就是框架活动、步骤和任务如何依据时间和顺序出现在框架活动中

1. Linear process flow

2. Iterative process flow Repeat one or more of the activities before proceeding to the next.

3. Evolutionary process flow

Execute the activities in a “circular” manner

4. Parallel process flow

Execute one or more activities in parallel with other activities

3. CMM and CMMI

用于评价软件机构的软件过程能力成熟度的模型。发展到后来，又同时被软件组织用于改进其软件过程。

Summary

• A generic process model for software engineering encompasses a set of framework and umbrella activities, actions, and tasks.
• Each process model can be described by a different process flow.
• Process pattern can be used to solved common problems that are encountered as part of the software process

---

第四章、Process Models

1. Prescriptive Process Models

Prescriptive process models (sometimes called “traditional” process models)
strive for structure and order in software development软件开发的结构和顺序

2. The waterfall and V model

1. 瀑布模型

基于软件生命周期的线性工作模型，提出了系统、顺序地开发软件。从用户规格说明书开始，通过策划、建模、构建、部署，提供完整软件和持续的软件支持

Merits

• a useful process model in situation where requirements are well defined and reasonably stable.

Demerits

• Real projects rarely follow the sequential flow. Changes can cause confusion as the project team proceeds.现实中工程很少遵循顺序流，改变可能会导致混乱
• The model requires customer to state all requirements explicitly and has difficulty accommodating the natural uncertainty that exits at the beginning of many project.这个模型要求客户明确所有的需求。在很多软件开始的时候很难集中一般的不确定性

• A working version of the program will not be available until late in the project time-span. 在项目最后才能使用软件

  2. The V-Model

  v-model改进了瀑布模型，在软件开发的生存期，开发活动和测试活动几乎同时的开始，这两个并行的动态的过程就会极大的较少bug和error出现的几率。在v-model中关键词就是parallel，是v-model的核心。

  3. The Incremental Model

  Combines elements of linear and parallel process flow
• 在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。

• 软件体系结构必须是开放的，即向现有产品中加入新构件的过程必须简单、方便

  4. Evolutionary Models

• Business and product requirements often change as development proceed.
• A set of core product or system requirements is well understood, but the details of product or system extensions have yet to be defined.
• Evolutionary models are iterative.
• Two common evolutionary models
• • Prototyping

• • The spiral model

    1. Prototyping

    原型是指模拟要开发的系统的原始模型。在软件过程中，原型是软件早期一个可运行的版本，它反映最终系统的部分重要特性，如界面、功能或者性能等等。

Merits：

• Serves as a mechanism for assisting developers and customers to better understand what is to be build when requirements are fuzzy.当需求模糊时用来帮助开发者和客户更好地理解将要构建什么软件

Demerits

• Customers always ask developers to make the prototype a working product, which makes software development management relented.客户总是想要把原型当成工作产品

• Developers often make implementation compromises in order to get a prototype working quickly. Finally, the less-than-ideal choices has now become an integral part of the system.开发者为了更快构建原型而用不好的数据结构、算法，不太理想的选择变成系统部分

  2. The Spiral Model

  Originally proposed by Barry Boehm[Boe88], the spiral model is an evolutionary process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model.
  螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。

螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。
增加了风险分析

3. Evolutionary Summary

• Modern computer software is characterized
• • by continual change,
• • by very tight time lines, and
• • by an emphatic need for customer-user satisfaction.
• If a market window is missed, the software project itself may be meaningless.如果错失市场时间。软件变得毫无意义
• Evolutionary process models were conceived to address these issues, and yet,
• • they too have weakness
• The intent of evolutionary models is to develop high-quality software in an iterative or incremental manner.以迭代和增量型式开发软件

• The challenge for software team is to establish a proper balance between these critical project and product parameters and customer satisfaction.

  5. Concurrent Model

• The concurrent model allows a software team to represent iterative and concurrent elements of any process model, and provides an accurate picture of the current state of a project.
• All activities exist concurrently but reside in different states.所有活动都是并行的但是以一种不同状态

• The concurrent model is often more appropriate for product engineering projects where different engineering teams are involved.适用于有不同的软件工程团队的软件工程

  6. The Unified Process (UP)

• use-case driven,
• architecture-centric,
• iterative and incremental

• and closely aligned with the Unified Modeling Language(UML).

  Summary

• Prescriptive process models
• • The waterfall and V model
• • Incremental process
• • Evolutionary process models, such as prototyping, spiral model
• • Concurrent model
• Specialized process models
• • Component-based model
• • Formal methods model

• PSP and TSP emphasize measurement, planning, and self-direction as a key ingredients for a successful software process.

---

建模

第八章、理解需求

理解需求是软件工程师所面临的最困难的任务之一

1. What Is A Requirement?

1997年IEEE在《软件工程标准词汇表》中对需求 （requirement）作出的定义为

(1) 用户为解决某一问题或为达到某个目标所需要的条件或能力。（需方）

(2) 系统或系统部件为满足合同、标准、规格说明或其他正式的强制性文档所必须具有的条件或能力。（供方）
对(1)和(2)中所描述的条件或能力的文档化说明。

Three Levels of Requirements

• Business requirements

  业务需求反映了组织或客户高层次的目标要求，通常问题定义本身就是业务需求。
  业务需求从总体上描述了为什么要开发系统（why），组织希望达到什么目标。

• User requirements

  用户需求描述了要求系统必须完成的任务，即用户能使用系统来做些什么（what）。

• Functional requirements

  功能需求描述开发人员应在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。

  2. Requirements Engineering

  1. 定义

• The broad spectrum of tasks and techniques that lead to an understanding of requirements is called requirements engineering.需求工程就是理解需求的一系列任务
• Requirements engineering is a software process action that begins during the communication activity and continues into the modeling activity.需求工程就是从沟通到建模的软件过程行为

• Requirements engineering establishes a solid base for design and construction.
  Without it, the resulting software has a high probability of not meeting customers’ needs需求工程建立起从设计到构建的根基，从而满足客户需求

  2.Requirements Engineering Tasks

1. Inception起始Q&A+分类+决策

   Establish basic understanding of
   the problem,
   the people who want a solution,
   the nature of the solution that is desired, and
   the effectiveness of preliminary communication and collaboration between the customer and the developer

Establish basic understanding，Identifying Stakeholders，Asking the First Questions，Recognizing Multiple Viewpoints，Working toward Collaboration，Working toward Collaboration，Nonfunctional Requirements，Traceability

1. Elicitation启发

   Ask the customer, the users, and others
   what the objectives for the system or product are,
   what is to be accomplished,
   how the system or product fit into the needs of the business, and,
   how the system or product is to be used on a day-to-day basis.

• Quality Function Deployment (QFD) is a quality management technique that translates the needs of the customer into technical requirements for software.

QFD identifies three types of requirements

• Normal requirements
• Expected requirements
• Exciting requirements

Developing Use Cases：Use case diagram provides a big picture of the functionality of the system

1. Elaboration精化

   Develop a refined requirements model(Chapters 9-11) that identifies various aspects of software information, function, and behavior

• analysis model / requirements model：Both refer to representations of information, functional, and behavioral domains that describe problem requirements.
• A set of generic elements is common to most requirements models.
• • Scenario-based elements

Use case
Use case diagram
Activity diagram(8/e,P155

• • Class-based elements
• • Behavioral elements：
    State diagram

Sequence diagram

• • Flow-oriented elements

    Data flow diagram(DFD) represents how data objects are transformed at they move through the system.
    数据对象在系统中流动时是如何转换的

1. Negotiation谈判

   Reconcile conflicts
   defines a set of negotiation activities:

• Identify the key stakeholders
• Determine each of the stakeholders “win conditions”
• Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win conditions for all concerned

1. Specification具体化

   Describe the requirements formally or informally.
   Specification can be any one (or more) of the following:

• A written document
• A set of models
• A formal mathematical model
• A collection of user scenarios (use-cases)
• A prototype

1. Validation确认

   Assess work products of requirement engineering for quality.

2. Management管理

   Help the project team identify, control, and track requirements and changes to requirements

   Summary

• Requirement engineering tasks are conducted to establish a solid foundation for design and construction.
• Requirement engineering encompasses seven tasks:
• • inception,
• • elicitation,
• • elaboration,
• • negotiation,
• • specification,
• • validation, and
• • management.
• Inception ask a set of questions that establish basic understanding.
• Elicitation elicit requirements from all stakeholders.
  -Elaboration develop a refined requirement model that identifies various aspects of software function, behavior, and information.
• Negotiation reconcile conflicts.
• Specification describe the requirements formally or informally.
• Validation assess work products of requirement engineering for quality.
• Management help the project team identify, control, and track requirements and changes to requirements

---

第九章、基于场景的需求建模

1. Requirements Analysis

1. Requirements analysis

• specifies software’s operational characteristics,具体化软件使用特点
• indicates software's interface with other system elements, and表明软件接口

• establishes constraints that software must meet建立起约束

  2. The requirements modeling action results in one or more of the following types of models:

• scenarios-based models,
• class-oriented models,
• behavioral models,
• data models,

• and flow-oriented models.

  3. 需求建模目标

• to describe what the customer requires,
• to establish a basis for the creation of a software design, and

• to define a set of requirements that can be validated once the software is built.

  4. Domain Analysis

  The goal of domain analysis is to find or create those analysis classes and/or analysis pattern that are broadly applicable so that they may be reused.

• Structured Analysis
  consider data and the processes that transform the data as separate entities.

• Object-oriented Analysis
  focus on the definition of classes and the manner in which they collaborate with one another

  5. 分析建模元素

  
  Scenario-Based Modeling：Requirements modeling with UML begins with the creation of scenarios in the form of
  use cases,
  activity diagrams, and
  swimlane diagrams.

  Summary

• The requirement model bridges the gap between a system-level representation and a software design.
• Scenario-based models depict software requirements from the user’s point of view.
  The use case is the primary modeling element.
• Use case diagram
• Activity diagram

• Swimlane diagram

---

第十一章、基于类建模方法

1. 基于类建模

1. Class-based modeling represents

• objects that the system will manipulate,
• operations (also called methods or services) that will be applied to the objects to effect the manipulation,
• relationships (some hierarchical) between the objects, and

• collaborations that occur between the classes that are defined

  2. The elements of a class-based model include

• classes and objects,
• attributes,
• operations,
• CRC models,

• collaboration diagrams, and
  packages.
  

  3. 步骤

1. Identify analysis classes.
2. Specify the attributes of each class.
3. Define operations of each class.

4. Establish basic class relationships and collaborations

   4. CRC Modeling

• The cards are divided into three sections.
• Along the top of the card you write the name of the class.
• In the body of the card you list the class responsibilities on the left and

• the collaborators on the right.

  Summary

• Class-based modeling use information derived from scenario-based and data modeling elements to identify analysis classes.
• • classes, attributes, and operations
• • CRC index cards
• • UML modeling notation for relationship
• • analysis packages

---

第11章、基于行为建模

1. 行为建模

Behavioral Model

Static elements

• Scenarios-based models

• Class-based models

  State Diagram

  
  State Diagrams vs. Sequence Diagrams
• State diagrams depict the state of the system and show how events affect system states.

• Sequence diagrams indicate how events cause transitions from object to object.
  顺序图
  

  2. Patterns for Requirements Modeling

  1. Patterns for Requirements Modeling

  2. Discovering Analysis Patterns

  3. Requirements Modeling for Web and Mobile Apps

• Content model
• Interaction model
• Functional model
• Navigation model

• Configuration model

  4. Software Requirements Specification

  5. Flow-Oriented Modeling

• It represents how data objects are transformed at they move through the system.

• Data flow diagram (DFD) is the diagrammatic form that is used

  Summary

• Behavioral modeling depicts dynamic behavior.
• • State diagrams
• • Sequence diagrams
• Requirements modeling methods
• • Structured analysis consider data and the processes that transform the data as separate entities.
• • Object-oriented analysis focus on the definition of classes and the manner in which they collaborate with one another.

---

设计概念

五个框架活动

• Communication
• Planning
• Modeling
• • Analysis of requirements
• • Design
• Construction
• • Code generation
• • Testing
• Deployment
  
  UML用例图使用场景
• 基于类元素：类图、CRC、分析包、协作图
• 基于行为元素：状态图、顺序图
• 基于场景元素：用例图、活动图、泳道图

设计创建了软件的表示或模型，但与需求模型（注重描述所需的数据、功能和行为）不同的是，设计模型提供了软件体系结构、数据结构、接口和构件的细节，这些是实现系统所必需的。

---

一、第十二章 设计概念

1. 四种设计

• data/class design：The data/class design transforms class models into design class realizations and the requisite data structures required to implement the software.

数据/类设计创造一个模块和信息代表着高水平模块抽象

• architecture design

is equivalent to the floor plan(平面图) of house

• interface design is equivalent to the windows,doors of house

The interface design describes how the software communicates with systems that interoperate with it , and with humans who use it. 
An interface implies a flow of information (e.g., data and /or control) and a specific type of behavior. 
Therefore, **usage scenarios and behavioral models** provide much of the information required for interface design.

• component design is a set of detailed for each room of house

The component-level design transforms structural elements of the software architecture into a procedural description of software components.
 Information obtained from the class-based models, and behavioral models serve as the basis for component design.

2. 良好的设计

良好的设计应该有以下几个特征

• 完整性和充分性：Complete and sufficient
• 原始性：Primitiveness
• 高内聚：High cohesion

• 低耦合：Low coupling
  Firmness,
  Commodity,
  Delight.

• 设计必须实现分析模型中的需求
• 对于代码生成人员、测试人员，设计必须是可读、可理解的

• 设计提供软件的全貌，从实现角度说明数据域、功能域、行为域

质量属性(FURPS)

• functionality
• usability
• reliability
• performance
• supportalitity

Design approaches

• Structured
• Object-oriented
• Aspect-oriented
• Model-driven
• Test-driven

任务集

3. 设计概念

• Abstraction—data, procedure, control

• Architecture—the overall structure of the software

  the structure or organizationof program components,
  the manner in which these components interact, and
  the structure of data that used by the components.

• Patterns—”conveys the essence” of a proven design solution

  A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design

• Separation of concerns—any complex problem can be more easily handled if it is subdivided into pieces

A concern is a feature or behavior that is specified as part of the requirements model for the software
模块化是关注点分离最常见的表现。

• Modularity-compartmentalization of data and function
• Information Hiding
  模块应当精心设计以使得模块中的信息不被不需要这些信息的其他模块所访问
  
• Functional independence—single-minded function and low coupling（单一功能和避免和其他模块过多的交互）

Cohesion is an indication of the relative functional strength of a module. 
- A cohesive module performs a single task, requiring little interaction with other components in other parts of a program. 
- Stated simply, a cohesive module should (ideally) do just one thing. 

Coupling is an indication of the relative interdependence among modules. 
- Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.

• Refinement—elaboration of detail for all abstractions（逐步求精）

  Stepwise refinement is a top-down design strategy.

• Aspects—a mechanism for understanding how global requirements affect design
• Refactoring—a reorganization technique that simplifies the design
• Dependency Inversion（依赖倒转原则）

• Design for Test

  “Advocates of test-driven development(TDD) write tests before implementing any other code.”

• Polymorphism

  多态性是指相同的操作或函数可作用于多种类型的对象上并获得不同的结果。
  不同的对象，收到同一消息可以产生不同的结果，这种现象称为多态性。
  Polymorphism is a characteristic that greatly reduces the effort required to extend the design.

内聚(cohesion)和耦合(couping)

• 内聚显示某个模块内部相关的程度
• 耦合表示不同模块依赖程度

• 好的设计应该高内聚低耦合

  4. The Design Model

  1. Data elements

  数据设计创建在高抽象级上（从用户的观点）表示的数据模型和（或）信息模型，之后该模型被逐步精化为系统能够处理的表示。

2. Architectural elements

The architectural design for software is the equivalent to the floor plan of a house.Architectural design elements give us an overall view of the software.

The architectural model [Sha96] is derived from three sources:

• information about the application domain for the software to be built;
• specific requirements model elements such as data flow diagrams or analysis classes, their relationships and collaborations for the problem at hand, and

• architectural patterns and styles

  3. Interface elements

The interface design for software is analogous to a set of detailed drawings for the doors, windows, and external utilities of a house.

Three important elements

• the user interface (UI)
• external interfaces to other systems, devices, networks or other producers or consumers of information
• internal interfaces between various design components

5. Component elements

The component-level design for software is the equivalent to a set of detailed drawings (and specifications

The component-level design defines

• data structure for all local data objects,
• algorithmic detail for all processing that occurs within a component, and

• an interface that allows access to all component operations

  6. Deployment elements

  Deployment-level design elements indicate how software functionality and subsystems will be allocated within the physical computing environment.

  Summary

• The goal of design is to create a model of software that will implement all customer requirements correctly.
• The design process begins by focusing on architecture.
• • Subsystems are defined; communication mechanisms among subsystems are established; components are identified, and a detailed description of each component is developed.
• • In addition, external, internal, and user interfaces are designed.
• Design concepts
• Design model elements
• • Data design elements
• • Architecture design elements
• • Interface design elements
• • Component-level design elements
• • Deployment-level design elements

---

第十三章 体系结构设计

1. 软件体系结构

软件体系结构是指系统中的一个或多个结构，结构中包括构件、构件的可见外部属性和他们之间的联系，体系构建不是可运行的程序

2. Architectural Descriptions

体系结构描述实际上是一组工作产品，这些产品反映了不同的利益相关者从不同的角度对系统的理解

The IEEE Standard defines an architectural description (AD) as a “a collection of products to document an architecture

3. “4+1” View Model

4. Architectural Styles

Each style describes a system category that encompasses:

• a set of components
• a set of connectors
• constraints
• semantic models(语义模型)

体系结构风格：

• Data-centered architectures
  
• Data flow architectures
  
• Call and return architectures
  
• Object-oriented architectures
  

• Layered architectures
  

  5. Architectural Design

1. Representing the system in context
   系统环境表示（ACD）
2. Defining a set of architectural archetypes
   定义原型集

• 原型是表示核心抽象的类或模式，该抽象对于目标系统体系结构的设计非常关键。是软件体系结构设计的核心抽象，但是随着软件体系结构的进行，这些抽象需要进一步精化
• 目标系统的体系结构由这些原型组成，可以基于系统行为以多种不同的方式对原型实例化。

1. Refining the architecture into components
   精化为构件

• Conventional approach
• • Components are derived from the data flow model.
• Object-oriented approach
• • The application domain is one source for the derivation and refinement of components.
• • Another source is the infrastructure domain.
• • The interface domain

1. Describing Instantiations of the System
   描述系统实例

   6. Architectural Description Language

• xArch
• Unicon
• Wright
• Acme

• UML

  7. Architecture Reviews

1. Assess the ability of the software architecture to meet the systems quality requirements and identify potential risks
2. Have the potential to reduce project costs by detecting design problems early
3. Often make use of experience-based reviews, prototype evaluation, and scenario reviews, and checklists

Pattern-Based Architecture Review

summary

• Software architecture provides a holistic（整体的） view of the system to be built.
• A number of different architectural styles and patterns are available to the software engineer and may be applied within a given architectural genre.
• Architectural design
• • Representing the system in context
• • Defining a set of architectural archetypes
• • Refining the architecture into components
• • Describing Instantiations of the System

---

第十三章、构件级设计

1. What is a Component?

1. 定义

“… a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.”一个模块，可部署、可替换的系统部分能够实现并且暴露一系列接口

--- OMG UML Specification [OMG01]

2. Different Views of Component

• Object-Oriented view

  A component contains a set of collaborating classes

  Further elaboration
• • Attribute: data structures
• • Operation: algorithmic detail
• • Interface: mechanisms, message communication between objects

• Traditional view

A traditional component, also called a module

1. Control component
2. Problem domain component
3. Infrastructure component

• Process-related view

2. Design Class-Based Components

1. Basic Design Principles

• The Open-Closed Principle (OCP)
  模块/构件应该对外延/扩展具有开放性，对修改具有封闭性。
  OCP背后的主要机制是抽象和多态。

• The Liskov Substitution Principle (LSP)

  “Subclasses should be substitutable for their base classes.”
  子类可以替换它们的基类。
  LSP是使OCP成为可能的主要原则之一。
  正是由于子类型的可替换性才使得使用基类类型的模块在无需修改的情况下就可以扩展。

• Dependency Inversion Principle (DIP)

  “Depend on abstractions. Do not depend on concretions.”
  依赖于抽象，而不是依赖于具体实现。

• The Interface Segregation Principle (ISP)

  “Many client-specific interfaces are better than one general purpose interface.”
  多个客户专用接口比一个通用接口更好。

  2. Four basic design principles

  Additional packaging principles
• The Release Reuse Equivalency Principle (REP)发布复用等价性原则
• The Common Closure Principle (CCP)
  共同封装原则

• The Common Reuse Principle (CRP)
  共同复用原则

  3. Conducting Component-level Design

  Conducting Component-level Design

1. Identify design classes in problem domain
2. Identify infrastructure design classes

Identify Classes

1. Elaborate design classes：Class Elaboration

• Specify message details when classes or components collaborate.
• Identify appropriate interfaces for each component.
• Elaborate attributes and define data structures required to implement them.
• Describe processing flow within each operation in detail.

1. Describe persistent data sources

   Describe persistent data sources (databases and files) and identify the classes required to manage them.
   描述持久数据源（数据库和文件）并确定管理数据源所需要的类

2. Elaborate behavioral representations

It is sometimes necessary to model the behavior of a design class

1. Elaborate deployment diagrams
2. Refactor design and consider alternatives

• Design is an iterative process

• The best designers will consider many alternative design solutions before settling on the final design model.

  4. Object Constraint Language (OCL)

  3. Designing Traditional Components

1. A traditional software component is often called module, procedure, or subroutine.

2. Structured design uses a set of constrained logical constructs
   sequence
   condition
   repetition

   Summary

• Component-level design ultimately depicts the software at a level of abstraction that is close to code.
• Three different view of component-level design
• • OO view focuses on the elaboration of design classes that come from both the problem and infrastructure domain.
• • Traditional view refines three different types of components or modules: control modules, problem modules, and infrastructure modules.
• • Process view focuses on reusable software components and design patterns.
• Basic design principles and concepts that lead to high-quality software are applied in OO design and traditional design.
• Cohesion and Coupling
• OO component-level design focuses on the elaboration of design classes.
• • Principles
• • Task set

• Traditional component-level design requires the representation of data structures, interfaces, and algorithms for a program module in sufficient detail.

  第十四章、 用户接口设计

1. 黄金法则：控制用户，减少用户记忆，界面一致
2. 四种模型：用户模型、设计模型、心理模型、实现模型

3. 用户界面分析框架活动：用户、任务环境分析和建模，接口设计，接口构建，接口确认。

   Summary

• Three important principles
• • Place the user in control
• • Reduce the user’s memory load
• • Make the interface consistent
• Interface analysis
• • User analysis
• • Task analysis
• • Display content analysis
• • Environmental analysis
• Interface design
• • Define a set of interface objects and actions
• • Create a screen layout
• • Refine the design model
• • Design issue

构建阶段 编码和测试

第22章、测试策略

Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user

Verification（验证） refers to the set of tasks that ensure that software correctly implements a specific function.
确保软件正确地实现某一特定功能的一系列任务
Validation（确认） refers to a different set of tasks that ensure that the software that has been built is traceable to customer requirements.
确保开发的软件可追溯到客户需求的另外一系列任务

1. 测试的顺序

• 单元测试：充分利用测试技术，检查构件中每个特定结构中的路径以便完全覆盖，从而发现错误
• 集成测试：处理并验证与程序构建相关的问题
• • Recovery testing
    forces the software to fail in a variety of ways and verifies that recovery is properly performed.
• • Security testing
    verifies that protection mechanisms built into a system will, in fact, protect it from improper penetration.
• • Stress testing
    executes a system in a manner that demands resources in abnormal quantity, frequency, or volume.
• • Performance testing
    test the run-time performance of software within the context of an integrated system.
• • Deployment testing
    sometimes called configuration testing, exercises the software in each environment in which it is to operate.
• 确认测试为满足功能、性能、行为需求的验证
• 系统测试：验证所有功能能正确合适的结合在一起

1. 软件测试指导原则：在开始测试之前以量化的方式具体产品需求；实施测试技术评审，以评估测试策略和测试用例
2. 单元测试要测试的单元

• 接口
• 本地数据结构
• 边界条件
• 独立路径
• 错误处理路径

1. 集成测试

• 自顶向下
• 自底向上
• 开关测试Sandwich testing uses top-down tests for upper levels of the program structure, coupled with bottom-up tests for subordinate levels.
• 回归测试：重新测试已经执行过的子集，以确保变更没有带来副作用
• 冒烟测试：滚动的集成测试，它让项目频繁进行评估

1. 面向对象的测试：
   集成测试：
   基于线程测试；基于使用测试
   面向对象软件的类测试等同于传统软件的单元测试。
   不同的是：
   传统软件单元测试侧重于模块的算法细节和模块接口数据；
   面向对象类的测试侧重于封装在该类中的操作和类的状态行为
2. 调试方法：蛮干法，回溯法，原因排除
3. 独立测试组
4. Alpha and Beta testing

• Alpha testing
• • α test is conducted at the developer’s site by a representative group of end users.
• • α tests are conducted in a controlled environment.
• Beta testing
• • β test is conducted at one or more end-user sites.
• • β tests are conducted in an environment that cannot be controlled by the developer.
• Customer acceptance testing is a variation on β testing.

1. Test Strategies for WebApp

• content
• functionality
• interface
• navigation
• performance

• security

  Summary

• Test strategies for conventional software
• • Unit testing
• • Integration testing
• Test strategies for OO software
• • Unit testing
• • Integration testing
• Validation testing
• • System testing
    Debugging

测试

1. 可测试性：简洁性、可观察性、稳定性、易于理解性等等
2. 好的测试：尽可能找到程序中的错误；不相关性、最佳品种，既不太简单也不太复杂
3. 黑盒测试：在软件接口处执行测试，不关心内部结构。等价类是黑盒测试
4. 白盒测试：基于内部构件的检查。保证内部操作按照规格说明书执行

优质内容筛选与推荐>>
1、VTK初学一，e_Triangle三角形的绘制
2、Linux与Windows间使用git
3、CentOS7.6使用Virt-manager创建虚拟机报错
4、order by
5、.Net中导出Excel中身份证等数字串的解决方式

赞赏

长按二维码向我转账

受苹果公司新规定影响，微信 iOS 版的赞赏功能被关闭，可通过二维码转账支持公众号。

阅读

已发送

发送中