1

Models

• Modelling can help us to understand the requirements thoroughly

• Ambiguous behaviour is revealed by holes in the models

• Inconsistencies in requirements are revealed by multiple, conflicting outputs to the same input

2

Requirements Modelling

• Consists of:– Decomposition

• the process by which a problem is broken down into parts

– Abstraction• a description of the problem at some level of generalisation

that allows us to concentrate on the key aspects of the problem without getting involved in the difficulties of the details.

– Separation of concerns• the process of breaking a program into distinct features that

overlap, as little as possible, in functionality

3

Purposes of Decomposition

• Requirements specification is decomposed along separate concerns to simplify the resulting model and make it easier to read and to understand

• In contrast , decomposition of a design improve the system’s quality attributes (modularity, maintainability, performance, time to delivery, etc.)

4

Unified Modelling Language

• UML is a collection of notations used to document software specifications and designs

• Represents a standard notation for modelling, documenting, and communicating decisions

• Modelling – helps us to understand requirements

– reveal inconsistencies in requirements (conflicting outputs to same input)

5

Notations - ERD• Entity-Relationship Diagrams

– Represents conceptual model and decomposes by entity– Popular for describing database schema– Mostly static, structural view and says nothing about how

entities are to behave

• Three core constructs, which are combined to specify a problem’s elements and inter-relationships:– Entities (collection of real-world objects)– Attributes (annotation that describes data or properties

associated with the entity)– Relations

6

Notations – UML class diagram

• ER diagram in which – entities are called actors– Class is a collection of similarly typed entities– Class has a name, set of attributes and operations

• Primarily for design notation but is used for conceptual modelling, in which classes represent real-world entities in the problem

• e.g. Conceptual model – Customer class which corresponds to CustomerRecord class in program class in implementation

7

Notations – Event Traces• Describes system’s behavioural requirements decomposed by

scenario– Not used to provide a complete description of required behaviour as

number of scenarios can become unwieldy

• Graphical depiction of a sequence of events that are exchanged between real-world entities– Vertical line represents timeline for an entity, whose name appears on top

of the line– Horizontal line represents and event or interaction between two entities

bounding the line, i.e. a message passed– Time progresses from top to bottom, i.e. an upper event happens before a

lower event

• Each graph represents a single trace, i.e. only one of the several possible behaviours

8

Notations – State Machines• Used to represent a collection of event traces in a single

model decomposed by control state– Used for specifying dynamic behaviour and for describing how

behaviour should change in response to the history of events that have already occurred

• Graphical depiction of all dialog between the system and its environment– Each node (state) represents a stable set of conditions that exist

between event occurrences– Each edge (transition) represents a change in behaviour or

condition due to the occurrence of an event• Labelled with a triggering event and possibly an output event generated

when transition occurs

9

Notations – UML Statechart Diagrams

• Depicts dynamic behaviour of objects in a UML class– Shows how class instances should change state and how

their attributes should change value as the objects interact with each other

• UML model is a collection of concurrently executing statecharts – one per instantiated object – that communicate with each other via message passing

• Each class in a UML class diagram has an associated statechart diagram that specifies the dynamic behaviour of objects of that class

10

Notations – Data-Flow Diagrams

• Promotes decomposition by functionality– Models functionality and the flow of data from one function

to another

• Representations:– Bubble process or function that transforms data– Arrow data flow, into bubble represents an input and out

of bubble represents an output– Data store is a formal repository or database of information

used to store data that persist beyond their use in a single computation

– Actors (data sources or sinks) are entities that provide input data or receive the output results

11

Notations – UML Use-case Diagrams

• Similar to top-level data-flow diagram that depicts observable, user-instantiated functionality in terms of interactions between the system and its environment.

• Components:– Large box represents system boundary– Stick figures outside box portray actors (humans and

systems)– Each oval inside box is a use case that represents some

major required functionality and its variants– Line between actor and use case indicates that actor

participates in the use case

12

Notations – UML Use-case Diagrams

• Use cases are not meant to model all the tasks in the system but used to specify user views of essential system behaviour

• Model only system functionality that can be initiated by some actor in the environment

13

Formal Methods/Approaches

• Mathematically based specification and design techniques

• Encouraged by software developers who build safety-critical systems

14

Advantages of Formal Methods

• Mathematical models are more precise and less ambiguous than other models

• Mathematical models lend themselves to more systematic and sophisticated analysis and verification

• Many formal specifications can be checked automatically for consistency, completeness, non-determinism, reachable states, type correctness

15

Functions and Relations• Some formal paradigms model requirements/ software

behaviour as a collection of mathematical functions or relations

• When function and relations are composed together, they map the system inputs to system outputs

• Functions– Specify state of a system’s execution– Specify outputs

• Relations– Used instead of a function whenever an input value maps to

more than one output value

16

Function

• Systematic and straightforward test for consistency and completeness– Because it maps each input to a single output,

by definition it is consistent– If it specifies an output for every distinct input,

total function, and is by definition complete

17

Logic

• Is a descriptive notation, which better expresses global properties and constraints– Descriptive notation describes a problem or

proposed solution in terms of its properties or its invariant behaviour

• Consists of:– a language for expressing properties– a set of inference rules for deriving new,

consequent properties from the stated properties

18

Logic

• Used to express a property of a software problem/system– This property is an assertion about the problem

or system that should be true– As such, a property specification represents

only those values of the property’s variables for which the property’s expression evaluates true

19

First-order logic

• Typed variables• Constants• Function• Predicates < and >• Equality• Logical connectives (and), (or), ¬ (not),

(implies), (logical equivalence)• Quantifiers (there exists) and (for all)

20

Temporal logic• Introduces additional logic connectives for

constraining how variables can change value over time– More precisely over multiple points in an execution

• The following (linear-time) connectives constrain future variable values, over a single execution trace: f f is true now and throughout the rest of the execution f f is true now or at some future point of the execution– f f is true in the next point of the execution– f W g f is true until a point where g is true, but g may

never be true

21

• Properties may be often used to augment a model-based specification either to:– Impose constraints on model’s allowable

behaviour• Property specifies behaviour not expressed in model

and the property

– Simply express redundant but non-obvious global properties

• Property does not alter specified behaviour but may aid in understanding the model by explicating otherwise implicit behaviour

• Also aids in requirements verification, by providing expected properties of the model for the reviewer to check

22

Algebraic specifications

• Used to specify the behaviour of operations by specifying the interactions between pairs of operations rather than modelling individual operations– Multi-operational view – viewing system in terms of

what happens when combinations of operations are performed

– Execution trace – a sequence of operations that have been performed since the start of execution

23

Algebraic specification axioms

• Specify the effects of applying pair operations on an arbitrary sequence of operations that has already been executed

24

Disadvantage of Algebraic specification

• For a collection of operations, it can be tricky to construct a concise set of axioms that is complete and consistent, and correct

25

Prototyping Requirements

• One way to elicit details• It solicits feedback from potential users about

what aspects they would like to see improved– which features are not so useful, or what functionality

is missing

• help determine whether customer’s problem has a feasible solution

• Assist in exploring options for optimising quality requirements

26

Rapid prototyping

• Involves building software to answer questions about requirements– Partial solution that is built to help us

understand the requirements or evaluate design alternatives

– Different from prototyping, in which prototype is a complete solution

• Whose purpose is to test and design product before automating / optimising manufacturing step for mass production

27

Types of Rapid PrototypingThrowaway• Developed to learn more

about a problem or a proposed solution, and is never intended to be part of delivered software

• Allows “quick-and-dirty” software to be built to be written, i.e. poorly constructed, inefficient, with no error checking

Evolutionary

• Developed not only to help us answer questions but also to be incorporated into the final product

• As such, more careful development is undertaken, because this software has to eventually exhibit quality requirements (e.g. response rate, modularity) of the final product– These qualities cannot be

retrofitted

28

Validation and Verification• Requirements validation

– Checks that our requirements definition accurately reflects all the stakeholder’s needs

• Requirements verification– Check that one document or artefact conforms

to another– Verifies that:

• Code conforms to design

• Design conforms to requirements specifications

• Requirements specification conforms to requirements definition

29

Requirements Validation

• Uses the following characteristics as the criteria for validating requirements:

– Correctness

– Consistency

– Unambiguity

– Completeness

– Relevance

– Testability

– Traceability

30

Requirements Validation Techniques• Checklist

– Common errors can be recorded in a checklist, which reviewers can use to guide their search for errors

• Reading– Reading document and report errors

• Walkthrough– One of the document’s authors presents the

requirements to the rest of the stakeholders, and asks for feedback

• Formal Inspection– Reviewers take on specific roles and follow prescribed

rules (when to meet or take breaks, when to schedule follow-up inspection)

31

Requirements Validation Techniques• Review

– Representative of developer’s staff and customer’s staff examine the requirements document individually

– Then they meet to discuss identified problems

– Customer’s representatives may include those who will:

• be operating the system

• prepare the system’s inputs

• use the system’s outputs

• manager of these employees who attend

– Developer’s representatives include:• design team

• test team

• process team

32

Requirements Verification

• Checking our requirements-specification document correspond to our requirements-definition document– Ensures a system ca be implemented that

• meets the specification

• satisfies customer’s requirements

• Most often, it is a check of traceability

33

Requirements Verification• For critical systems, we may want to demonstrate that the

specification fulfils the requirements– prove that the specification realises every function, event, activity

and constraint in the requirements

• To do this we need to make assumptions about how the environment behaves– Assumptions about what inputs the system will receive– Assumptions about how the environment will react to outputs

• We rely on our environment to help us satisfy the customer’s requirements– If our assumptions about how the environment behave is wrong,

then our system may not work as the customer expects