software process 软件过程

A Software Process is a set of activities whose goal is the development or evolution of software

  • Specification - what the system should do and its development constraints
  • Development - production of the software system (design and implementation)
  • Validation - checking that the software is what the customer wants
  • Evolution - changing the software in response to changing demands

Attributes of Good Software 软件属性要求

  • Maintainability - Software must (easily) evolvable to meet changing needs
  • Dependability - Software must be trustworthy (work with all data)
  • Efficiency - Software should not make wasteful use of system resources
  • Usability - Software must be usable by the users for which it was designed

Issues of Professional Responsibility 专业责任问题

  • Confidentiality 保密

Engineers should normally respect the confidentiality of their employers or clients even without a formal confidentiality agreement.

  • Competence 为能力担责

Engineers should not misrepresent their level of competence. They should not knowingly accept work which is beyond their competence.

software process 软件过程

Specification - what the system should do and its development constraints Development - production of the software system (design and implementation) Validation - checking that the software is what the customer wants Evolution - changing the software in response to changing demands

1. Software development process:software life cycle

Specifying 规定 Designing 设计 Implementing 实现 Testing 测试

2. Software Process Models

  • The Waterfall Model 瀑布模型,从上到下

    Separate and distinct phases of specification and development

    • Inflexible partitioning of the project into distinct stages, difficult to respond to changing customer requirements.

    • 先总体考量,可靠,但灵活性低,开发周期长——军用/航天/银行等


  • Evolutionary Development 进化开发

    Specification and development are interleaved

    based upon the idea of developing an initial implementation , exposing it to the user and refining it based upon their response. 基于开发初始实现的想法,将其公开给用户,并根据用户的响应对其进行优化。

  • Agile and Scrum 敏捷开发

    Used widely in industry today

    那啥Test driven其实行业里不管的



  • Incremental Development (Scrum) 增量开发

    • Customer value can be delivered with each increment so system functionality is available earlier

    • Early increments act as a prototype to help elicit requirements for later increments

    • Lower risk of overall project failure

    • The highest priority system services tend to receive the most testing

3. Software Design and Implementation

The process of converting the system specification into an executable system

The activities of design and implementation are closely related and may be inter-leaved


4. Design Process Activities

Architectural design (separate web service modules) 架构设计

  • The sub-systems making up the system and their relationships are identified and documented.

Abstract specification 抽象规范

  • For each sub-system, an abstract specification of its operational constraints and services is produced.

Interface design 接口设计

  • For each sub-system, an unambiguous interface with other sub-systems is designed and documented
    • Formal specification may be used in this stage (we study this later)

Component design 组件设计 (for 接口

  • Services are allocated to components and the interfaces of these components are designed

Data structure design 数据结构设计

  • The data structures used in the system implementation are designed in detail and specified

Algorithm design 算法设计

  • The algorithms used in components to provide services are designed and specified

5. Design Methods

Design (structured) methods are systematic approaches to developing a software design

The design is usually documented as a set of graphical models


6. Programming and Debugging

  • Programming and Debugging consist of translating a design into a program and removing errors from that program

  • Programming is usually personal activity - there is no generic programming process, but there are good programming practices and organisational standards to be followed.

  • Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process

7. Testing Stages



  • Unit testing Individual components are tested

  • Module testing Related collections of dependent components are tested

  • Sub-system testing (merges with system testing) Modules are integrated into sub-systems and tested. The focus here should be on interface testing

  • System testing Testing of the system as a whole. Testing of emergent properties

  • Acceptance testing Testing with customer data to check that it is acceptable



User requirements  Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers System requirements  A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor Software specification  A detailed software description which can serve as a basis for a design or implementation. Written for developers




Functional requirements

  • Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations
  • 定义了对系统提供的服务或功能的约束,包括时间约束、空间约束、开发过程约束及应遵循的标准等。
  • 定义了系统或系统元素必须有资格执行并且必须以不同形式记录的功能。描述了系统的行为,因为它与系统的功能相关。

Non-functional requirements

  • constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Usually defined on the system as a whole
  • Define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. They are often emergent properties 涌现特性 of the system.
  • Process requirements may also be specified, mandating a particular CASE system, programming language or development method
  • 与软件的功能方面无关。它们可以是指定可用于决定操作的标准的必需品,而不是系统的特定行为。基本的非功能性需求是——可用性、可靠性、安全性、存储、成本、灵活性、配置、性能、法律或监管要求等。
  • 在运行时可观察到的执行质量,如安全性和可用性。
  • 软件系统的静态结构中体现的可测试性、可维护性、可扩展性和可伸缩性等演化特性。
  • Product requirements
    • Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, security etc.
  • Organisational requirements
    • Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. (Java as programming language)
  • External requirements
    • Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc. (Must conform to FIPS


Domain requirements

  • Requirements that come from the application domain of the system and that reflect characteristics of that domain

  • 软件开发常常会涉及一些未知领域,而开发的软件需要遵守这些领域的一些规则等,这就是领域需求。


In principle requirements should be both complete and consistent:

Complete 完整性

  • They should include descriptions of all facilities required

Consistent 一致性

  • There should be no conflicts or contradictions in the descriptions of the system facilities

In practice, it is very difficult or impossible to produce a complete and consistent requirements document

Use case

Use-Cases are a scenario based technique in the Unified Modeling Language (UML) which identify the actors in an interaction and which describe the interaction itself. • A set of use-cases should describe all possible interactions with the system. • Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system (we shall study sequence diagrams later).

• Actor 不一定是人,Can be non human - Sensor (smoke detector) - Payment service (credit cards) - Geo location - Robotic arm


Requirements Engineering Processes

  1. Requirements elicitation 需求发现(获取) What services do the end-users require of the system?
  2. Requirements analysis 需求分析 How do we classify, prioritise and negotiate requirements?
  3. Requirements validation 需求验证 Does the proposed system do what the users require?
  4. Requirements management 需求管理 How do we manage the (sometimes inevitable) changes to the requirements document?


Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders. Stakeholders may be classified under different viewpoints. This multi-perspective analysis is important as there is no single correct way to analyse system requirements.


There are two types of interview

  • Closed interviews where a pre-defined set of questions are answered.
  • Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.


In ethnography, a social scientist spends a considerable amount of time observing and analysing how people actually work.

Requirements that are derived from the way that people actually work rather than the way in which process definitions suggest that they ought to work.

Focused Ethnography

Developed in a project studying the air traffic control process Combines ethnography with prototyping

The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant. Ethnography 可能会去研究一些曾经存在但以不相关的东西


Confidentiality requirements

Usually two main options Encryption (hard security) Permissions (soft security) Data must be kept secure In storage (final or intermediary) On the wire or wireless link For as long as reasonably possible

Integrity Requirements

Messages or data must not be modifiable without

Integrity approaches : CRC Checking, Hash……


Authentication Who are you? Authorization What are you allowed to do? Techniques Usernames, Passwords, hardware (cards, dongles), Biometrics

Non-repudiation issue 不可抵赖性

Non repudiation is built on

  • Authentication
  • Integrity
  • Recording and time stamping
  • Broker style services

Availability requirements



9s terminology not always useful

Security, logs and alerts Security is very dependent on knowledge of activity (audits and logs) Standard log (records all logins/logouts, database access requests) Failed login log (records all failed logins) Unusual activity log (high volume transactions on account) Alert log (failed logins for top level clearance users) Alerts Unusual activity can be used to alert operators, suspend accounts etc.

Bell–LaPadula model


Requirements Checking Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology? Verifiability. Can the requirements be checked? This reduces the potential for disputes between customers and contractors and a set of tests should be possible.

System Models

Detailed system requirements may be expressed in a more technical way however

  • One widely used technique is to document the system specification as a set of system models

  • These are graphical representations which describe business processes and the system to be developed

  • They are an important bridge between the analysis and design processes

System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers


They can be easier to understand than using a verbose natural language description

System models can leave out unnecessary details of the system so way may focus on what is important

  • A system representation should maintain all the information of a system
  • An abstraction deliberately simplifies the system and picks out its most salient characteristics

Different models can focus on different approaches to abstraction


They do not model non-functional system requirements They do not usually include information about whether a method is appropriate for a given problem They may produce too much documentation System models are sometimes too detailed and difficult for users to understand

Model Types

Data processing model - showing how the data is processed at different stages Composition model - showing how entities are composed of other entities Architectural model - showing principal sub-systems Classification model - showing how entities have common characteristics Stimulus/response model - showing the system’s reaction to events

Context Models

Context models are used to illustrate the boundaries of a system Identifying the boundaries of the system to be developed is not always straightforward Social and organisational concerns may affect the decision on where to position system boundaries Architectural models show the system and its relationship with other systems

Process Models

Process models show the overall process and the processes that are supported by the system

  • In process models it is implicit 1 process is completed before another process begins
  • Process models are similar to flow charts

Data flow models may be used to show the processes and the flow of information from one process to another

  • The data flow models it is implicit that processes will happen in parallel (concurrent processing)

Behavioural Models

  • Behavioural models are used to describe the overall behaviour of a system

Two types of behavioural model

  • Data processing models that show how data is processed as it moves through the system
  • State machine models that show the systems response to events

Both of these models are required for a description of the system’s behaviour

Data-Processing Models Data flow diagrams are used to model the system’s data processing These show the processing steps as data flows through a system IMPORTANT part of many analysis methods Simple and intuitive notation Show end-to-end processing of data


Data Flow Diagrams Data Flow Diagrams track and document how the data associated with a process is helpful to develop an overall understanding of the system Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment

Data Flow Diagrams 数据流图 Data Flow Diagrams have an advantage in that they are simple and intuitive and can thus be shown to users who can help in validating the analysis Developing data flow diagrams is usually a top-down process

  • We begin by evaluating the overall process we wish to model before considering sub-processes

Data flow diagrams show a functional perspective where each transformation represents a single function or process which is particularly useful during requirements analysis since it shows end-to-end processing.




Statechart Diagrams 状态图

​ Statechart Diagrams (or State machine models ) show the behaviour of the system in response to external and internal events ​ They show the system’s responses to stimuli (the event-action paradigm) so are often used for modelling real-time systems ​ Statechart diagrams show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another ​ Statecharts are an integral part of the UML

​ An initial state is denoted by a solid circle and is optional (sometimes the system will start in different places and thus the initial state should be omitted). ​ If required, a final state can also be used; this is denoted by a solid circle with a ring around it. ​ We use a level of abstraction so that we can observe the essential behaviour of the system we want to model. ​ Rounded rectangles are used for states. Each state contains two components, the state name and a brief description of the action performed in that state (see next slide).

初始状态由一个实心圆表示,并且是可选的(有时候系统会从不同的地方开始,因此初始状态应该被省略)。 如果需要,还可以使用最终状态;这是用一个带环的实心圆表示的。 我们使用一个抽象级别,这样我们就可以观察我们想要建模的系统的基本行为。 圆角矩形用于表示状态。每个状态包含两个组件,州名和在该状态下执行的操作的简要描述(见下一张幻灯片)。


Statecharts also allow the decomposition of a model into sub-models (see figure on next slide). A brief description of the actions is included following the ‘do’ in each state (the word “do” is optional). Can be complemented by tables describing the states and the stimuli.


The label on an arc can denote the method called to move from one state to the next (the event). A guard is used to ensure that the system only moves from one state to the other if the expression is satisfied. A state can contain a subdiagram within it (also called a composite state). This is useful for example when we wish to model a subsystem or substates. On the next slide, we can see all these elements of a UML statechart diagram



More hints on state charts Often have an Idle state where the process is not active 通常处于Idle状态,此时进程不是活动的 All states need some exit (no deadlock, even in error conditions) 所有状态都需要一些退出(没有死锁,即使在错误的情况下) Use multiple state charts to keep the design simple 使用多个状态图来保持设计的简单性 Do NOT need to have a state chart as sub state of other state chart 不需要将状态图作为其他状态图的子状态

  • System can be described by multiple state machines running concurrently 系统可以由多个并发运行的状态机来描述

Finite State Machines 有限状态机

Finite State Machines (FSM), also known as Finite State Automata (FSA) are models of the behaviours of a system or a complex object, with a limited number of defined conditions or modes, where mode transitions change with circumstance.



A model of computation consisting of

  • a set of states 一组状态
  • a start (initial) state 一个初始态
  • an input alphabet 一份输入字符 表(集合)
  • a transition function that maps input symbols and current states to a next state 状态转移函数

Computation begins in the start state with an input string. It changes to new states depending on the transition function.


states define behaviour and may produce actions state transitions are movement from one state to another rules or conditions must be met to allow a state transition input events are either externally or internally generated, which may possibly trigger rules and lead to state transitions.

Variants of FSMs 变体

machines having actions (outputs) associated with transitions (Mealy machine) or states (Moore machine)

  • Mealy machine:输出取决于(输入和)状态
  • Moore machine:输出仅取决于状态

multiple start states

transitions conditioned on no input symbol (a null) or more than one transition for a given symbol and state (nondeterministic finite state machine 非确定性有限状态机 )

one or more states designated as accepting states (recognizer 识别器)

Moore Machine

Basically a Moore machine is just a FSA with two extra attributes.

  1. It has TWO alphabets, an input and output alphabet.
  2. It has an output letter associated with each state. The machine writes the appropriate output letter as it enters each state.


​ a b a b 如图:q0 -> q1 -> q1 -> q3 -> q2 ​ 1 0 0 1 0



Mealy Machine

Mealy machines are computationally equivalent to Moore machines,we can implement any Mealy machine using a Moore machine, and vice versa

However, Mealy machines move the output function from the state to the transition. This turns out to be easier to deal with in practice, making Mealy machines more practical.

Transitions are labelled i/o where:

i is a character in the input alphabet o is a character in the output alphabet.


Mealy machines are complete in the sense that there is a transition for each character in the input alphabet leaving every state.

There are no accept states in a Mealy machine because it is not a language recogniser, it is an output producer. Its output will be the same length as its input.

Petri Net Models

A Petri Net is a collection of directed arcs connecting places and transitions.

Places may hold tokens (黑点).

The state or marking of a net is its assignment of tokens to places



Arcs have capacity 1 by default; if other than 1, the capacity is marked on the arc, or else we use multiple arrows to denote the capacity (i.e. 5 arrows for capacity 5).

Places have infinite capacity by default.

Transitions have no capacity, and cannot store tokens at all.

Arcs can only connect places to transitions and vice versa.

A few other features and considerations will be added as we need them.


A transition is enabled when the number of tokens in each of its input places is at least equal to the arc weight going from the place to the transition.

fire 开火

An enabled transition may fire at any time.



When fired, the tokens in the input places are moved to output places, according to arc weights and place capacities. This results in a new marking of the net, a state description of all places.

Firing is atomic (only one transition fires at a time, even if more than one is enabled)

Creating 生产

A transition without any input can fire at any time and produces tokens in the connected places



Consuming 消耗

A transition without any output must be enabled to fire and deletes (or consumes) the incoming token(s):


Inhibition 抑制



A Collection of Primitive Structures that Occur in Real Systems:



High-Level Petri Nets


High-level Petri nets are Petri nets extended with colour (for the modelling of attributes) time (for performance analysis) hierarchy (for the structuring of models, DFD's)



represent the above state as (1,2,1,1) for (p1,p2,p3,p4)

Non-Determinism 非确定


Two transitions fight for the same token: conflict. Even if there are two tokens, there is still a conflict. The next transition to fire (t1 or t2) is arbitrary (non-deterministic).















Formal Specifications 正式规范

Formal specification is part of a more general collection of techniques that are known as ‘formal methods 正式方法

principal benefits of formal methods:reducing the number of errors in systems. can be used in critical systems.

Specification and design are inextricably mixed.

Architectural design is essential to structure a specification. 在乎结构

Formal specifications are expressed in a mathematical notation with precisely defined vocabulary, syntax and semantics. 在乎数学表达和语法

Specification Techniques (Behavioural Specification)

Algebraic approach The system is specified in terms of its operations and their relationships

Model-based approach The system is specified in terms of a state model that is constructed using mathematical constructs such as sets and sequences. Operations are defined by modifications to the system’s state

Interface Specification 接口规范

Specification of subsystem interfaces allows independent development of the different subsystems

Interfaces may be defined as abstract data types or object classes

  • The algebraic approach is well-suited to interface specification

Algebraic Specification 代数规范


Introduction – Declares the sort (the type name) of the entity being specified, i.e., a set of objects with common characteristics. It also imports other specifications to use. Description – An informal description of the operations to aid understanding. Signature – Defines the syntax of the interface to the abstract data type (object), including their names, parameter list and return types. Axioms – Defines the semantics of the operations by defining axioms characterising the behaviour.


Specification Operations

Constructor operations. Operations which create entities of the type being specified. Inspection operations. Operations which evaluate entities of the type being specified. To specify behaviour, define the inspector operations for each constructor operation.

Abstract State Machine Language (AsmL) 抽象状态机语言

An AsmL model is said to be abstract because it encodes only those aspects of the system’s structure that affect the behaviour being modelled The goal is to use the minimum amount of detail that accurately reproduces (or predicts) the behaviour of the system that we wish to model

Problem: Suppose we have a set that includes the integers from 1 to 20 and we want to find those numbers that, when doubled, still belong to the set.


Solution (with AsmL)

A = {1..20} C = {i | i in A where 2*i in A} Main() step WriteLine(C)



Design Methodology 设计方法论

Stages of Design 设计的各个阶段:

Problem understanding 了解问题 Look at the problem from different angles to discover the design requirements. Identify one or more solutions 确定方案 Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources. Describe solution abstractions 方案抽象化 Use graphical, formal or other descriptive notations to describe the components of the design. Repeat process for each identified abstraction 重复抽象 until the design is expressed in primitive terms. 直到设计被原始项表达

设计过程 Design Process

Any design may be modeled as a directed graph made up of entities with attributes which participate in relationships.

The system should be described at several different levels of abstraction.

Design takes place in overlapping(相互重叠) stages. It is artificial to separate it into distinct phases but some separation is usually necessary.


Design Phases 各个阶段的设计

Architectural design: Identify sub-systems. • Abstract specification: Specify sub-systems. • Interface design: Describe sub-system interfaces. • Component design: Decompose sub-systems into components. • Data structure design: Design data structures to hold problem data. • Algorithm design: Design algorithms for problem functions.

Modularity 模块化!

The goal of computer system design is to decode: What the modules are; What the modules should do; How the modules interact with one-another

modularity cannot bring benefits unless the modules are : autonomous 自主的 coherent 连贯的 robust 稳固的

procedural abstraction 过程抽象

involve functional decomposition


Programs as Functions:the program is viewed as a function from a set I of legal inputs to a set O of outputs.


Object-Oriented Design 面向对象设计

• The system is viewed as a collection of interacting objects 交互对象集合. • The system state is decentralized 分散的 and each object manages its own state. • Note , use of internal state against functional programming • Objects may be instances of an object class and communicate by exchanging messages.

Five Criteria for Design Methods

We can identify five criteria to help evaluate modular design methods: Modular decomposability Modular composability Modular understandability Modular continuity Modular protection

Modular Decomposability 模块可分解性

In general, this method will be repetitive: sub-problems will be divided still further Top-down design methods fulfil this criterion; stepwise refinement is an example of such a method

Modular Composability 模块可组合性

Composability is directly related to the issue of reusability Note that composability is often at odds with decomposability; top-down design, for example, it tends to produce modules that may not be composed in the way desired This is because top-down design leads to modules which fulfil a specific function, rather than a general one

Top-Down Design 自顶向下

In principle, top-down design involves starting at the uppermost components in the hierarchy and working down the hierarchy level by level. • In practice, large systems design is never truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process.


Modular Understandability 模块可理解性


• Related to several component characteristics – Can the component be understood on its own? – Are meaningful names used? – Is the design well-documented? – Are complex algorithms used? • Informally, high complexity means many relationships between different parts of the design.


Modular Continuity 模块连续性

a method satisfies this criterion if it leads to the production of software such that a small change in the problem specification leads to a change in just one (or a small number of ) modules. 局部变化只影响局部模块

EXAMPLE. Some projects enforce the rule that no numerical or textual literal should be used in programs: only symbolic constants should be used COUNTER EXAMPLE. Static arrays (as opposed to dynamic arrays) make this criterion harder to satisfy.

Modular Protection 模块保护性

a method satisfied this criterion if it yields architectures in which the effect of an abnormal condition at run-time only effects one (or very few) modules 局部异常只影响局部模块

EXAMPLE. Validating input at source prevents errors from propagating throughout the program (design by contract) COUNTER EXAMPLE. Using int types where subrange or short types are appropriate.

Repository Models 存储库模型

All shared data is held in a central database which may be accessed by all sub-systems











a good system:

We may remark that a good system has the following properties: Useful and usable; Reliable; Flexible; Affordable; Available.

Module Interfaces 模块接口

An interface to a module defines some features of the module upon which other parts of the system may rely. It is thus an abstraction of the module. Encapsulation of the module means that users of the module cannot know more about the module than is given by the interface. Any assumptions about interfaces should be documented in the interface. This means that any changes to the internals of a module not causing a change to the interface should not necessitate a change to other parts of the system.


​ 因此,它是模块的抽象。 模块的封装意味着模块的用户对模块的了解不能超过接口提供的信息。


​ 这意味着,对模块内部的任何更改不会导致对接口的更改,因此也不需要对系统的其他部分进行更改。

Five Principles for Good Design

Linguistic modular units; 语言模块化

  • Modules must correspond to linguistic units in the language used

Few interfaces; 少接口

  • Every module should communicate with as few others as possible, system should stay closer to the minimum links.

Small interfaces; 小接口(松耦合)

  • If any two modules communicate, they should exchange as little information as possible.

Explicit interfaces; 显式接口

  • If modules A and B communicate, this must be obvious from the documentation of A or B or both.
    • Why? If we change a module, we need to see what other modules may be affected by these changes. A traceability matrix can be used for this purpose.

Information hiding. 隐藏信息

  • All information about a module, (and particularly how the module does what it does) should be private to the module unless it is specifically declared otherwise.
    • Thus each module should have an interface, which is how the world sees it anything beyond that interface should be hidden.

例子可见 CRC Cards in PPT

Coupling 耦合

Coupling is a measure of the strength of the inter-connections between system components.


Loose coupling means component changes are unlikely to affect other components.

Shared variables or control information exchange lead to tight coupling (usually bad).

Loose coupling can be achieved by state decentralization (as in objects) and component communication via parameters or message passing.

Object-oriented systems are loosely coupled 面向对象的系统是松散耦合的 because there is no shared state and objects communicate using message passing.

However, an object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes.

Cohesion 内聚

A measure of how well a component “fits together” 对组件“配合程度”的衡量

A component should implement a single logical entity or function.

Cohesion is a desirable design component attribute as when a change has to be made, it is localized in a single cohesive component.

Various levels of cohesion have been identified.

The concept of cohesion is not well-defined and is often difficult to classify. 内聚的概念没有明确的定义,而且经常很难分类。

nheriting attributes from super-classes weakens cohesion. To understand a component, the super-classes as well as the component class must be examined. Object class browsers assist with this process.

Cohesion Levels 内聚等级

Coincidental cohesion (weak) • Parts of a component are simply bundled together.

Logical association (weak) • Components which perform similar functions are grouped.

Temporal cohesion (weak) • Components which are activated at the same time are grouped.

Communicational cohesion (medium) • All the elements of a component operate on the same input or produce the same output.

Sequential cohesion (medium) • The output for one part of a component is the input to another part.

Functional cohesion (strong) • Each part of a component is necessary for the execution of a single function.

Object cohesion (strong) • Each operation provides functionality which allows object attributes to be modified or inspected.

Cohesion versus Encapsulation 内聚和封装

Cohesion is a measure of abstraction that means developers do not need concern themselves with the internal working of a module.内聚是一种抽象度量,它意味着开发人员不需要关心模块的内部工作。

Encapsulation means that developers are unable to use hidden information within a module, ensuring that subtle errors cannot be introduced when using connected modules. 封装意味着开发人员不能使用模块中的隐藏信息,从而确保在使用连接的模块时不会引入细微的错误。

This is a subtle(微妙) but important difference between the two concepts.

High Cohesion, Low Coupling Modules 高内聚 低耦合 模块

If a module has high cohesion, low coupling and a well defined interface, then it may be feasible to reuse that module in other systems, i.e., it may be a pluggable module. 高内聚低耦合且定义良好的接口在其他系统中重用可能是可行的,也就是说,它可插拔。

​ *This will also depend upon the architecture in which the module was developed

Stepwise Refinement 逐步求精法

The simplest realistic design method, widely used in practice. Not appropriate for large-scale, distributed systems: mainly applicable to the design of methods.

Start with a high-level spec of what a method is to achieve; 从高处开始 Break this down into a small number of problems (usually no more than 10) 拆分问题 For each of these problems do the same; 重复拆分 Repeat until the sub-problems may be solved immediately. 直到拆得足够简单

Distributed System Architectures 分布式系统架构

Architectural design for software that executes on more than one processor

Architectural Design

Architectural design should be an early stage of the system design process Represents the link between specification and design processes Often carried out in parallel with some specification activities It involves identifying major system components and their communications

Architectural Design Process

System structuring The system is decomposed into several principal sub-systems and communications between these sub-systems are identified Control modelling A model of the control relationships between the different parts of the system is established Modular decomposition The identified sub-systems are decomposed into modules

Architectural Models Different architectural models may be produced during the design process Each model presents different perspectives on the architecture: Static structural model

  • show the major system components

Dynamic process model

  • show the process structure of the system

Interface model

  • define sub-system interfaces

Relationships model

  • such as a data-flow model

System Structuring

Concerned with decomposing the system into interacting sub-systems The architectural design is normally expressed as a block diagram presenting an overview of the system structure (More specific models showing how sub-systems share data, are distributed and interface with each other may also be developed)


The Repository Model 仓库模型

Sub-systems must exchange data

Shared data is held in a central database or repository and may be accessed by all sub-systems Each sub-system maintains its own database and passes data explicitly to other sub-systems

Client-Server Architecture 客户-服务器结构

Set of stand-alone servers which provide specific services such as printing, data management, etc. Set of clients which call on these services Network which allows clients to access servers


Advantages Distribution of data is straightforward Makes effective use of networked systems. May require cheaper hardware Easy to add new servers or upgrade existing servers Disadvantages No shared data model so sub-systems use different data organisation. data interchange may be inefficient Redundant management in each server No central register of names and services - it may be hard to find out what servers and services are available

Control Models

Centralised control 集中控制模型

One sub-system has overall responsibility for control and starts and stops other sub-systems

Firstly, there is the call-return model

​ Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systems ​ Such a model is embedded into familiar programming languages such as C, Java, Pascal etc.


If the controlled subsystems run in parallel, then we may use the manager model of centralised control: Manager model Applicable to concurrent systems. One system component controls the stopping, starting and coordination of other system processes. Can also be implemented in sequential systems as a case statement.


Event-based control 事件控制 Each sub-system can respond to externally generated events from other sub-systems or the system’s environment

Driven by externally generated events where the timing of the event is out of the control of the sub-systems which process the event

There are two principal event-driven models:

  • Broadcast models. An event is broadcast to all sub-systems. Any sub-system which can handle the event may do so

    • Effective in integrating sub-systems on different computers in a network

    • Sub-systems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the event

    • Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them

    • However, sub-systems don’t know if or when an event will be handled


  • Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing

    • Used in real-time systems where fast response to an event is essential

    • There are known interrupt types with a handler defined for each type

    • Each type is associated with a memory location and a hardware switch causes transfer to its handler

    • Allows fast response but complex to program and difficult to validate


Modular Decomposition 模块分解

Another structural level where sub-systems are decomposed into modules Two modular decomposition models covered

  • An object model where the system is decomposed into interacting objects
  • A data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline model

*If possible, decisions about concurrency should be delayed until modules are implemented

Object Models

Structure the system into a set of loosely coupled objects with well-defined interfaces Object-oriented decomposition is concerned with identifying

  • object classes
  • their attributes
  • operations

When implemented, objects are created from these classes and some control model used to coordinate object operations


Data-Flow Models Functional transformations process their inputs to produce outputs May be referred to as a pipe and filter model (as in UNIX shell) Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems Not really suitable for interactive systems


Distributed Systems

System Types 类型

Personal systems that are not distributed and that are designed to run on a personal computer or workstation. Embedded systems that run on a single processor or on an integrated group of processors. Distributed systems where the system software runs on a loosely integrated group of cooperating processors linked by a network.

Characteristics 性质


  • Resource sharing Openness Concurrency Scalability Fault tolerance Transparency


  • Complexity Security Manageability Unpredictability
Middleware 中间件

Software that manages and supports the different components of a distributed system.

Middleware is usually off-the-shelf 现成的 rather than specially written software


Transaction processing monitors

Data converters

Communication controllers

Multiprocessor Architectures 多处理器架构

Simplest distributed system model

System composed of multiple processes which may (but need not) execute on different processors Architectural model of many large real-time systems Distribution of process to processor may be pre-ordered or may be under the control of a dispatcher


Client-Server Architectures 又是客户-服务器结构

The application is modelled as a set of services that are provided by servers and a set of clients that use these services Clients know of servers but servers need not know of clients Clients and servers are logical processes The mapping of processors to processes is not necessarily 1 : 1




Layered Application Architecture

Presentation layer 表示层 Concerned with presenting the results of a computation to system users and with collecting user inputs Application processing layer 应用处理层 Concerned with providing application specific functionality e.g., in a banking system, banking functions such as open account, close account, etc. Data management layer 数据管理层 Concerned with managing the system databases

Thin and Fat Clients 胖瘦用户

Thin-client model 所有应用程序处理和数据管理都在服务器上执行。客户端只负责运行演示软件。

Used when legacy systems are migrated to client server architectures.

A major disadvantage is that it places a heavy processing load on both the server and the network

Fat-client model 服务器只负责数据管理。客户端软件实现应用程序逻辑以及与系统用户的交互。

More processing is delegated to the client as the application processing is locally executed

Most suitable for new client-server systems where the capabilities of the client system are known in advance

More complex than a thin client model especially for management. New versions of the application have to be installed on all clients

Three-Tier Architectures 三阶框架

In a three-tier architecture, each of the application architecture layers may execute on a separate processor Allows for better performance than a thin-client approach and is simpler to manage than a fat-client approach A more scalable architecture - as demands increase, extra servers can be added to the data management or application processing layers.

Distributed Object Architectures 分布式对象结构

There is no distinction in a distributed object architectures between clients and servers

Each distributable entity is an object that

  • provides services to other objects and
  • receives services from other objects

Object communication is through a middleware system called an object request broker (software bus) However, they can be more complex to design than client-server systems


It allows the system designer to delay decisions on where and how services should be provided

  • Service-providing objects can execute on any node of the network and thus the distinction between thin/fat-client models becomes irrelevant.

It is a very open system architecture that allows new resources to be added to it as required

  • Object communication standards have been developed allowing objects written in different languages to communicate with each other.

The system is flexible and scalable

  • New objects can be added as the load on the system increases without disrupting the other system objects. Replicated object can be created to cope with load.

It is possible to reconfigure the system dynamically with objects migrating across the network as required

  • This may be important when there is fluctuating patterns of demand on services. A service-providing object can migrate to the same processor as service-requesting objects, thus improving performance.

Concepts of Object Oriented Design 面向对象设计

Object orientation means to organize the software as a collection of discrete objects that incorporate both data structure and behaviour. System functionality is expressed in terms of object services.

Don’t think of what an object holds – but what it will do for you

object 对象

*对象的定义 balabala …… a thing you can interact with

objects are defined by their interfaces

An object is a thing which has behaviour state identity

Advantages: Shared data areas are eliminated. Objects communicate by message passing. 没有公用数据,对象之间通信 Objects are independent and encapsulate state and representation information. Their independence can lead to easier maintenance. 对象是独立的,好维护


The way an object acts and reacts, in terms of its state changes as message passing. An object understands certain messages, it can receive the message and act on them. The set of messages that the object understands, like the set of attributes it has, is normally fixed.


The state of the object is all the data which it currently encapsulates An object normally has a number of named attributes (or instance variables or data members) each of which has a value Some attributes can be mutable (variable) An attribute ADDRESS other attributes may be immutable (constant) Date of birth Identifying number

Identity is more Tricky

The idea is that objects are not defined just by the current values of their attributes An object has a continuous existence For example the values of the object’s attributes could change, perhaps in response to a message, but it would still be the same object.

Interfaces 接口

The object’s public interface defines which messages it will accept

An object can also send to itself any message which it is capable of understanding (in either its public or private interface)

So typically an object has two interfaces: The public interface (any part of the system can use) The larger private interface (which the object itself and other privileged parts of the system can use)

Object Interface Specification 接口规范 Object interfaces have to be specified so that the objects and other components can be designed in parallel. Objects may have several interfaces which are viewpoints on the methods provided. Hiding information inside objects means that changes made to an object do not affect other objects in an unpredictable way.

Classification 分类

Each object is an instance of a class Each object knows its class Each instance has its own value for each attribute (state) but shares the attribute names and operations with other instances of the class also “static” i.e. class variables A class encapsulates data and behaviour, hiding the implementation details of an object

Classes and Types are different.

Remember that a class does not only define what messages an object understands! It also defines what the object does in response to the messages.

靠,基本上就是抄ppt 不记了,以上到 p19,PPT:

Unified Modelling Language(UML)

UML is a language for: Specifying Visualizing Documenting the parts of a system under development

Naming classes



Of the various models in UML, we have the categories:

Use case models – describing a system from the users’ point of view;

Static models – describing the elements of the system and their relationship; class models fall into this category;

Dynamic models – describing the behaviour of the system over time.


There are two main (extreme) techniques used to find classes in general:

Data-driven-design (DDD) – We identify all the data of the system and divide it into classes. We then assign particular responsibilities (methods) to these classes.

数据驱动设计(DDD) - 我们识别系统的所有数据并将其划分为类。然后我们将特定职责(方法)分配给这些类

Responsibility-driven-design (RDD) – We identify all the responsibilities of the system and divide them into classes. We then find the data each class requires.

责任驱动型设计(RDD) - 我们确定系统的所有职责并将其划分为多个类别。然后我们找到每个类所需的数据。

Instances of a classes are called objects;

Instances of associations are called links in UML

Class A and B are Associated if( some object of class A has to know about some object of class B

​ an object of class A sends a message to an object of class B

​ an object of class A creates an object of class B

​ an object of class A has an attribute whose values are objects of class B or collections of objects of B

​ an object of class A receives a message with an object of class B as argument

Operation Signatures

The signature of an operation gives the selector, names and types of all formal parameters (arguments) and the return type. For example:


Inheritance / Generalization

Generalization is a conceptual relationship between classes

Inheritance is an implementation relationship.

Generalization obviously increases the coupling of a system and if a subclass is changed it usually necessitates a recompilation of the subclass also (this is a pragmatic issue).

PPT 20: Aggregation, Composition, Navigability, Derived Associations, Abstract Classes

Verification and Validation 验证和确认

Ensuring that a software system meets a user's needs

Verification and validation should establish a degree of confidence that the software is fit for purpose


Verification: "Are we building the product right"

The software should conform to its specification

Validation: "Are we building the right product"

The software should do what the user really requires

Software inspections Concerned with analysis of the static system representation to discover problems (static verification)

​ May be supplement by tool-based document and code analysis

Software testing Concerned with exercising and observing product behaviour (dynamic verification)

​ The system is executed with test data and its operational behaviour is observed


Program Testing

Can reveal the presence of errors NOT their absence !!!

A successful test is a test which discovers one or more errors

Program testing is the only validation technique for non-functional requirements

Should be used in conjunction with static verification to provide full V&V coverage


Defect testing

​ Tests designed to discover system defects.

​ A successful defect test is one which reveals the presence of defects in a system.

Statistical testing

​ Tests designed to reflect the frequency of user inputs. Used for reliability estimation.


Software function – A much higher level of confidence that the system is fit for purpose is required for safety critical systems that for prototype systems for example

User expectations – Users sometimes have a low expectation of software and are willing to tolerate some system failures (although this is decreasing)

Marketing environment – Competing programs must be taken into account and the required schedule for introducing the product to market. Cheaper products may be expected to have more faults.

Defect testing and debugging are distinct processes

(!) Verification and validation is concerned with establishing the existence of defects in a program

(!!) Debugging involves:

formulating a hypothesis about program behaviour

​ then testing these hypotheses to find the system error


The Structure of a Software Test Plan

The testing process - a description of the major phases of the testing process

Requirements traceability – testing should ensure that all requirements are individually tested

Tested items – Specify the products of the software process to be tested

Testing schedule – An overall schedule for the testing of the software is required and resources (time and personnel) must be allocated as part of the general project schedule

Test recording procedures – The results of tests must be systematically recorded, it is not enough to simply run the tests. This allows an audit of the testing process to check it has been carried out correctly (imagine a safety critical system; procedures for auditing the tests are often necessary)

Hardware and software requirements – This part of the document sets out a list of software tools required and the estimated hardware utilisation

Constraints – Any constraints affecting the testing process should be anticipated in this section

Software Testing p611

Defect Testing

Defect testing involves testing programs to establish the presence of system defects

The goal of defect testing is to discover defects in programs

A successful defect test is a test which causes a program to behave in an anomalous way

Tests show the presence not the absence of defects


Component testing

Testing of individual program components

Usually the responsibility of the component developer (except sometimes for critical systems)

Tests are derived from the developer’s experience

Integration testing

Testing of groups of components integrated to create a system or sub-system

The responsibility of an independent testing team

Tests are based on a system specification

Black-box Testing

An approach to testing where the program is considered as a ‘black-box

The program test cases are based on the system specification

Test planning can begin early in the software process


Structural Testing / white-box testing / glass box

Sometime called white-box testing

Derivation of test cases according to program structure. Knowledge of the program is used to identify additional test cases

Objective is to exercise all program statements (not all path combinations)



Cyclomatic Complexity

The number of tests to test all control statements equals the cyclomatic complexity

Cyclomatic complexity equals number of conditions in a program plus one (or equivalently, in the program flow graph it is the “Number of edges - Number of nodes +2” 边-点+2)

Conditions are any type of branching operation such as each “if” statement or any types of loop (for, while etc.)

Useful if used with care. Does not imply adequacy of testing. Although all paths are executed, all combinations of paths are not executed



Testing Approaches

Architectural validation

​ Top-down integration testing is better at discovering errors in the system architecture

System demonstration

​ Top-down integration testing allows a limited demonstration at an early stage in the development

Test implementation

​ Often easier with bottom-up integration testing

Test observation

​ Problems with both approaches. Extra code may be required to observe tests

Testing Levels

Testing operations associated with objects

Testing object classes

Testing clusters of cooperating objects

Testing the complete OO system

Project Management

Management activities

  • Proposal writing

    Project planning and scheduling

    Project costing

    Project monitoring and reviews

    Personnel selection and evaluation

    Report writing and presentations

Project planning

  • Introduction

    Project organisation

    Risk analysis

    Hardware and software resource requirements

    Work breakdown

    Project schedule

    Monitoring and reporting mechanisms


Project scheduling

Split project into tasks and estimate time and resources required to complete each task

Organize tasks concurrently to make optimal use of workforce

Minimize task dependencies to avoid delays caused by one task waiting for another to complete

Dependent on project managers intuition and experience

Risk management

  • Technology risks

​ People risks

​ Organisational risks

​ Requirements risks

​ Estimation risks

Risk identification

​ Identify project, product and business risks

Risk analysis

​ Assess the likelihood and consequences of these risks

Risk planning

​ Draw up plans to avoid or minimise the effects of the risk

Risk monitoring

​ Monitor the risks throughout the project

Software Cost Estimation

Software Cost Components

Hardware and software costs

Travel and training costs

Effort costs (the dominant factor in most projects)

​ salaries of engineers involved in the project

​ Social and insurance costs

Effort costs must take overheads into account

​ costs of building, heating, lighting

​ costs of networking and communications

​ costs of shared facilities (e.g library, staff restaurant, etc.)

Estimation Techniques

Algorithmic cost modelling

Expert judgement

Estimation by analogy

Parkinson's Law

Pricing to win