Answers to mock test here provided by James Saeed. For my answers to the mock test, find them here:

Hey all! You know that list of questions that'll be on the exam? Someone has organised by how many there are as well as what lecture slides they are:

Topic | Questions | Slides
Nets, Petri nets | 6Q | 8 - 10
Java programming (Private scope, Extends, dynamic binding) | 5Q | 17/19
Use cases | 5Q | 17
Security, Including Bell-laPudla | 5Q | 6
Testing | 5Q | 22-24
Functional/Non-functional requirements | 4Q | 4
Class diagram | 4Q | 19/20
Formal specification and ASML | 2Q | 11/12
Cohesion & coupling | 2Q | 2/4/6/7/9/10-12/14/17
UML Diagrams | 2Q | 18-21
Flow graphs & Testing | 2Q | 7
Interaction question | 2Q | 21
Project management | 2Q | 25
Methodology (Waterfall, incremental) | 2Q | 2
Code estimation | 1Q | 26
State charts| 1Q | 7
OO design inheritance & encapsulation | 1Q | 17

I ordered them by the lecture slide numbers instead of how many questions:

Topic | Questions | Slides
Cohesion & coupling | 2Q | 2/4/6/7/9/10-12/14/17
Methodology (Waterfall, incremental) | 2Q | 2
Functional/Non-functional requirements | 4Q | 4
Security, Including Bell-laPudla | 5Q | 6
Flow graphs & Testing | 2Q | 7
State charts| 1Q | 7
Nets, Petri nets | 6Q | 8 - 10
Formal specification and ASML | 2Q | 11/12
Use cases | 5Q | 17
OO design inheritance & encapsulation | 1Q | 17
Java programming (Private scope, Extends, dynamic binding) | 5Q | 17/19
Class diagram | 4Q | 19/20
UML Diagrams | 2Q | 18-21
Interaction question | 2Q | 21
Testing | 5Q | 22-24
Project management | 2Q | 25
Code estimation | 1Q | 26

This blog post features all lecture slides mentioned above. Enjoy ✨

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

What is a requirement?

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification
This is inevitable as requirements may serve a dual function
May be the basis for a bid for a contract - therefore must be open to interpretation
May be the basis for the contract itself - therefore must be defined in detail
Both of these statements may be called requirements

Types of 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

Functional and non functional requirements

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
Domain requirements
Requirements that come from the application domain of the system and that reflect characteristics of that domain

Requirements imprecision

Problems arise when requirements are not precisely stated
Ambiguous requirements may be interpreted in different ways by developers and users
Consider the term ‘recover password’ from previous slide..
User intention – mechanism which allows the user to view the password after going through an authentication procedure
Developer interpretation – allowing the user to reset their password so that it can be set again (e.g. using email link)
Before development is to commence requirements should be defined as precisely as possible

guidelines for writing requirements

Invent a standard format and use it for all requirements
Use language in a consistent way. Use
shall for mandatory requirements (that must be supported),
should for desirable requirements (that are not essential).
See RFC 2119
Use text highlighting to identify key parts of the requirement
Avoid the use of computer jargon
Try and make documents self contained (e.g. include glossaries and complete examples)

A feasibility study decides whether or not the proposed system is worthwhile.

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.


Broken down into 4 main issues
Authentication and Authorization
One auxiliary issue
Availability  (Performance security)

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

Messages or data must not be modifiable without
Knowledge of the change
Integrity approaches
CRC Checking (no good, easy to forge check value)
Hash value over data, similar problem to CRC
Hash value over data + secret value
Key distribution problem
Hash value encrypted using asymmetric cipher
Best approach to date

Who are you?
What are you allowed to do?
Usernames, Passwords, hardware (cards, dongles), Biometrics
Often first point of attack

May require
Trusted broker, third party
Funding in Escrow
Non repudiation is built on
Recording and time stamping
Broker style services

9s terminology not always useful
Imagine a computer system
Three 9s available but unavailability spread as 78 seconds per day
Or Five 9s available, failing once every 10 years for 50 minutes
So ideally to need specify
Worst case scenarios
Worst case delay as well as down time
How the system can degrade gracefully

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)
Unusual activity can be used to alert operators, suspend accounts etc.

Belle-LaPadula Model

All items given security clearance level
Top-Secret (4), Secret(3), Sensitive(2), Unclassified
no read-up
A subject cannot read a document above their clearance level
If I am cleared to level 2, I cannot read a level 3 or 4 document
no write-down
A document cannot be copied/included with another document with a lower security clearance
So if I want to add a top secret to a sensitive document the result will be a top secret document
If my classification is 2, I cannot produce an unclassified document
Trusted subjects
Can write documents down
Must be shown trustworthy with regard to the security policy

Ideally kept as open as possible to allow for
Upgrading of encryption algorithms and protocols
Security policy
Shredding documents
Secure disposal
Password reset protocols
Security training
Security audits
Standards compliance
Payment Card Industry Data Security Standard

System Models

User requirements must be written in such a way that non-technical experts can understand them, e.g., by using natural language
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

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 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 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

DPD context diagram

level 0 DFD
Level 1 DFD

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 Unified Modeling Language (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

Often have an Idle state where the process is not active

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 Automata

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.

AAAAAAA, ABBA - any combination of A's and B's.

A model of computation consisting of

a set of states,

a start (initial) state,

an input alphabet, and

a transition function that maps input symbols

and current states to a next state

You may recall finite state

machines (or automata)

from COMP209.

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.

A model is an abstract system view. Complementary types of model provide different system information.

Context models show the position of a system in its environment with other systems and processes.

Data flow models may be used to model the data processing in a system.

State machine models model the system’s behaviour in response to internal or external events

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.

There are many variants, for instance,

machines having actions (outputs) associated with transitions (Mealy machine) or states (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), etc.

Finite state automata are like computers in that they receive input and process the input by changing states.

The only output that we have seen finite automata produce so far is a yes/no at the end of processing.

We will now look at two models of finite automata that produce more output than a yes/no.

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.

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 Nets

Petri Nets were developed originally by Carl Adam Petri (when he was 12), and were the subject of his dissertation in 1962.

Originally to model chemical reactions

Since then, Petri Nets and their concepts have been extended, developed, and applied in a variety of areas.

While the mathematical properties of Petri Nets are interesting and useful, the beginner will find that a good approach is to learn to model systems by constructing them graphically.

TODO lecture 10

Formal Specification

We're going to skip a bunch of slides now because the questions skp slides, but I'm going to include the stuff that looks important.

Use cases


Verifaction and validation