Solution
Question 1
(i)
(Part (a) is covered in Chps 2 and 3. Part (b) spans the whole course text)
(a) One main cause of the mismatch is that single requirements may be
implemented by code in many classes and a single class contributes
towards several requirements. Hence there is both scattering of
requirements throughout the code and tangling of code to support
multiple requirements.
Another reason is that requirements are usually expressed as functionality
(as in use cases) while designs are based around structure with classes and
methods; use cases and classes do not match well.
(b) This is a rather open question and many practices may be discussed.
For instance:
use of analysis and design models to bridge the gap between requirements and
code
evolving analysis and design models from domain models which are expressed
in the vocabulary of the application domain
short incremental and iterative development cycles to adjust to changing needs of
stakeholders
partitioning requirements through use cases from which operation
specifications and test cases are developed
applying sound design principled to improve the cohesion of design models, hence
of derived implementation code
(ii)
(These topics are covered in chapters 2 and 3 of the course text)
(a) Here is a possible interpretation:
The organization has members, several centres and provides several types of
facilities which can be booked.
A facility may be provided by one or more centres and a centre may provide
one or more facilities.
Bookings are made for one facility and for one centre.
HappyLeisure is the system class which keeps track of instances of relevant
business objects in the system.
(b) Here are possible invariants (others are possible):
context Booking inv.
- the facility of a booking has to be provided by the centre
- for which the booking is made
self.centre.facility -> includes (self.facility)
OR
self.facility.centre -> includes (self.centre)
context Booking inv;
- booking for a centre has to be made by a member of the centre
seif.centre.member -> includes (self.member)
context Booking inv.
- a member can only book a facility if offered by the centre to which they hold
membership
self.member.centre -> includes(self.facility.centre)
Question 2
(i)
(Modeling spans the whole course text)
• activity diagrams represent behaviour; they are typically used to model processes in
the business domain, but they can also be used to model operations
•
•
•
class diagrams represent structure (classes and their associations); they are
used to model structures within an application domain or within a software
system
statecharts represent behaviour: they are typically used to model the behaviour
of class instances
interaction diagrams represent behaviour; they are typically used to model the
way object interacts to accomplish the functionality of the system
(ii)
(These topics are covered primarily in chapter 3 of the course text)
(a) Use cases serve as a partition of the system functionality; they are
therefore a natural basis to plan iterations and increments of the
system. They can also be used as a means to establish
priorities of development by associating a ranking with the identified
use cases. This ranking can be established in terms of risk,
coverage and criticality. Use cases are also a main tool in the
development of tests for the system, hence for validating each
increment of development.
(b) Here are possible steps:
1. Identify actors - human actors are usually easy to identify as they are
the users of the system; they are the ones that need the use case.
And/Or
Identify triggers - sometimes it is easier to identify the triggers that start some portion of
functionality which will consist of a use case.
2. Associate some functionality to the identified actor (what the actor
wants from the system) or trigger (which functionality is started by the
trigger).
If there is a domain model, use cases can be identified as tasks that are
carried out by concepts in the model.
3. Name the use cases and detail them with precondition, goal and detail
success scenario and exceptions.
Question 3
(i)
(These topics are covered primarily in Chapter 11 of the course text)
1. identity
Each object is distinguished by its object identity , which is assigned and maintained by the
run-time system.
Each row in a relational database table is distinguished by the value(s) of its primary key
column(s) - value identity, which is typically supplied by the user.
2. associations
With object technology the mechanism used to represent associations is applicable for
associations of all multiplicities: not only one-to-many associations but also one-to-one and
many-to-many. With relational database technology one-to-one and many-to-many
associations have to be represented differently from one-to-many associations.
With object technology associations are navigated (by message passing) in a particular
direction. With relational database technology associations are not navigated but are
realised as a table by the join operation.
3. inheritance
Relational database technology does not support inheritance.
4. data types
A predefined data type provided by an object-oriented programming language may be
incompatible with the similar data type provided by the relational DBMS e.g. Boolean, or no
direct equivalent data type may be available.
(ii)
(These topics are covered primarily in chapter 5 of the course text)
Both inheritance and delegation are used during implementation to maximize code reuse
By applying inheritance, a class becomes the subclass of an existing class, from which it
inherits attributes and methods. The subclass can, of course, add new attributes and methods,
or override those of its superclass. Objects of the subclass
can make use of any attribute or method defined in the superclass as though they
were their own, and can substitute for an object of the superclass.. Inheritance is about
implementing generalisation/specialisation; i.e. defining a class which is a subtype of its
superclass. For instance, Car is a subtype of Vehicle
By applying delegation, a class A makes use of some or all of the services of another
class B in order to fulfil some of its responsibilities. Objects of class A hold
references to objects of class B which they use to invoke class B's methods
.
In delegation, no subtyping relationship exists between the two classes.
For instance, make use of Java HashSet to represent a StampCollection.
Questioin 4
(i)
Confidentiality: restrict access to authorised users only.
Integrity: maintain correctness/prevent corruption.
Availability: prevent loss and ensure accessibility in time and place.
(ii)
Confidentiality: enables control of who is accessing an information asset.
Integrity: enables control of who modifies an information asset.
Availability: enables control of who manages (esp. stores, erases) information assets.
(iii)
The Standard does not attest to level of security, only to its appropriate management.
Undertake a risk assessment of the contracted organisation and compare with contracting
organisation.
Audit assets to be handled and controls specified in own ISMS/SoA against those to be
adopted in outsourcing organisation to assure benchmark level compliance.
(iv)
Planning involves designing and implementing the ISMS.
Doing involves the implementation of the ISMS, including training and awareness.
Checking seeks to monitor and review the effectiveness of the ISMS.
Acting involves appropriate modification of the ISMS in the light of the Checking and
changed circumstances affecting the organisation and its priorities.
Question 5
(i)
(a)
feedback from interested parties/stakeholders;
(b)
independent review;
(c)
status of preventive and corrective actions;
(d)
management review;
(e)
process performance and information security policy compliance;
(f)
horizon scanning reports on changes that could affect the organisation's approach to
managing information security, including changes to the organisational environment,
business circumstances, resource availability, contractual, regulatory, and legal
conditions, or to the technical environment;
(g)
trends related to threats and vulnerabilities;
(h)
(i)
reported information security incidents;
recommendations provided by relevant bodies.
(ii)
The Standard gives:
(a)
information in: ...contracts and agreements, system documentation, research
information, user manuals, training material, operational or support procedures,
business continuity plans, fallback arrangements, audit trails, and archived
information;
(b)
software assets: application software, system software, development tools, and
utilities;
(c)
physical assets: computer equipment, communications equipment, removable
media, and other equipment;
(d)
services: computing and communications services, general utilities, e.g. heating,
lighting, power, and air-conditioning;
(e)
people, and their qualifications, skills, and experience;
intangibles, such as reputation and image of the organisation.
(iii)
Personnel; 70% of all recorded incidents are caused by internal staff of which only 5% are
deliberate.
(iv)
1
Mobile phone with camera may be used to copy protected documents
2
Mobile phone as remote listening device.
3
CCTV for unauthorised tracking.
WiFi laptops for unauthorised tracking.
Question 6
[25 marks]
(i)
Fingerprint, iris scan.
Many biometrics give an unacceptable* high number of false negatives'.
(ii)
An encrypted message digest which is appended to a plaintext or encrypted message to
verify the identity of the sender. The signature is encrypted with the user's private
key and
can only be decrypted with the corresponding public key.
(iii)
Description of organization, including (planned) ISMS management structure
Description of boundaries
Description of critical assests
Identification of key information security issuses.