COMP201笔记
简介
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其实行业里不管的
灵活，模块化，周期短，但整体性差，容易返工
取决于"PM"识别优先级，会有隐患
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
requirements
从对象来分类：
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
从性质来分类
ppt：https://liverpool.instructure.com/courses/46117/files/6013903?module_item_id=1189930
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
软件开发常常会涉及一些未知领域，而开发的软件需要遵守这些领域的一些规则等，这就是领域需求。
https://ifs.host.cs.st-andrews.ac.uk/Books/SE9/Web/Requirements/DomainReq.html
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
https://liverpool.instructure.com/courses/46117/files/6196312?module_item_id=1189932
• 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
https://liverpool.instructure.com/courses/46117/files/6013910?module_item_id=1189934
- Requirements elicitation 需求发现(获取) What services do the end-users require of the system?
- Requirements analysis 需求分析 How do we classify, prioritise and negotiate requirements?
- Requirements validation 需求验证 Does the proposed system do what the users require?
- Requirements management 需求管理 How do we manage the (sometimes inevitable) changes to the requirements document?
Viewpoints
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.
Interviewing
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.
Ethnography
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 可能会去研究一些曾经存在但以不相关的东西
Security
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/Authorization
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
https://en.wikipedia.org/wiki/Bell%E2%80%93LaPadula_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
Advantages
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
Weaknesses
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.
Definition
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.
- It has TWO alphabets, an input and output alphabet.
- 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
开始会先有输出。因为Moore模型输出仅取决于状态，而开始虽然没有输入，但机器必然处于某一状态，因此输出比输入多一位。
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
Capacity
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.
Transitions
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
上面那张图与前后的weight不一样，其实也产生了新的token。
Consuming 消耗
A transition without any output must be enabled to fire and deletes (or consumes) the incoming token(s):
Inhibition 抑制
该arc类型表示，只有当P1为空时，transaction才会被触发：
A Collection of Primitive Structures that Occur in Real Systems：
High-Level Petri Nets
PPT: https://liverpool.instructure.com/courses/46117/files/6013911?module_item_id=1189941
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).
状态分类
区分位置
对于不同位置，我们要做区分，比如下图，两个位置分别代表一种颜色，可以使用(n,m)表示目前状态存在n个位置A的token，m个位置B的token：
加入颜色
这个颜色不仅仅是颜色，它包含了大量的信息，是一种属性的统称。
加入时间
tmin、tmax代表transaction处理操作的最小和最大时间
加入等级
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.
假设有一个包含了从1到20整数的集合，我们想要找到翻倍后仍然属于这个集合的数。
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
https://liverpool.instructure.com/courses/46117/files/6013915?module_item_id=1189949
优势包括:
数据库是一种共享大量数据的有效方法，数据不需要在不同的子系统之间转换(它们同意单一的数据表示)。
产生数据的子系统不需要关心其他子系统如何使用这些数据。
许多标准操作，如备份、安全、访问控制、恢复和数据完整性都是集中的，可以由单个存储库管理器控制。
数据模型通过存储库模式可见。
缺点包括:
子系统必须就数据模型达成一致，这意味着必须做出妥协，例如在性能方面。
演化可能是困难的，因为生成了大量的数据，翻译可能是困难和昂贵的。
不同的系统对安全、恢复和备份策略有不同的要求，这些要求可能很难在单个数据库中实施。
将存储库分发到许多不同的机器上可能会很困难。
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 性质
advantages
- Resource sharing Openness Concurrency Scalability Fault tolerance Transparency
disadvantages
- 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
Examples：
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
Advantages
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. 对象是独立的，好维护
Behaviour
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.
state
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: https://liverpool.instructure.com/courses/46117/files/6013940?module_item_id=1189957
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
p581开始
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
Testing
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.
Goals
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