Exam prep

Question 1

Traceability

Answer 1

Track progress to demonstrate the delivery of requirements and reconstruct steps taken, such as in response to changes.

Can use documentation, and agile practises. TDD and user stories contribute to traceability by recording code and user requirements changes.

Question 2

Business rule

Answer 2

Constraints on the operation of the business, not necessarily related to the system. E.g. policy

Question 3

Business process

Answer 3

Activities or responsibilities of the business which may translate to the proposed system.

Question 4

Validation

Answer 4

The right thing is being built.

The process of checking what has been implemented is satisfiable and meets the proposed requirements.

Not to be confused with verification - checking the system is correct and relevant to the business rules.

Question 5

Verification

Answer 5

The process of checking if the system is correct and relevant to the specification and business rules.

Question 6

Singleton pattern

Answer 6

Where only one instance of a class is desired.

E.g. a UI component where multiple objects communicate with a single UI instance, or a main system coordination class. Multiple instances could lead to problems from objects in different states leading to unwanted behaviour.

Question 7

Adapter pattern

Answer 7

Where multiple components with different interfaces must interact.

The Adapter provides a common interface which bridges communication between the Classes through an Adapter class. This avoids incompatibility, with the Adapter acting as the mediator which supplies the interface.

Question 8

Service Oriented Architecture (SOA)

Answer 8

Independently designed services which can be integrated, tested and changed without affecting the core system, as they are not tightly coupled.

Often based around microservices which use web protocols like HTTP to serve external resources, e.g. a REST API.

Question 9

Main benefit of services

Answer 9

Saves development time and increases flexibility compared to working within the constraints of a monolithic architecture, where each change could have a large impact on the whole system.

Question 10

Difference between services and components

Answer 10

Whereas a component must be attached to the existing system and may require an adapter, a service is an independent external resource often based around web protocols, e.g. a REST API. This avoids the problems of compatibility.

Question 11

Actors

Answer 11

The main roles in the proposed system. Not simply a list of classes. Actors utilise or interact with the system in some way and are directly involved in the business processes.

e.g. Staff, Customer, Administrator, User (generalisation)

Question 12

Use case success criteria

Answer 12

Walkthrough of the steps to a successful outcome. Lists the activities in the correct order of completion, similar to an activity diagram.

Can include addition extensions, such as alternate branching steps in the walkthrough.

Question 13

Functional requirements

Answer 13

Things the system must do. The core tasks regardless of constraints on how they are achieved (non-functional).

Should not be statements about the properties or quality of a system (non-functional). Derived from requirements elicitation, business domain, user stories etc.

e.g. “The system shall accept a credit card number from the client.”

Question 14

Non-functional requirements

Answer 14

Qualities of the system and constraints on the functional requirements.

Typically organised by category:

• Look-and-feel; design and appearance
• Usability and humanity; ease-of-use and accessibility
• Performance; speed, accuracy, reliability
• Operational and environment; conditions the product must function under (e.g. under water, outdoors, 24/7)
• Maintainability and support; changes, updates, time allowed
• Cultural; special considerations for the users of the product
• Legal; laws, standards and regulations which apply
• Security; how secure the system is, confidentiality, protections

Question 15

Fit criteria

Answer 15

A condition or measurement which can be used to objectively test if the requirement has been satisfied.

For functional requirements this should be a true/false condition; e.g. “The user has been registered with an account.”

For non-functional requirements it should include a measurement; e.g. “90% of experienced customers should take no more than 30 seconds to make a withdrawal”, “The system shall function correctly up to 48hrs at a time.”

Question 16

Agile motivation/objective

Answer 16

Put people and working software over extensive planning and documentation.

Question 17

Main benefits of Agile

Answer 17

Flexible development process which can easily adapt to the changing requirements, resulting in better software which is fit for purpose.

Question 18

How agile uses modelling

Answer 18

Avoid creating UML models which aren’t relevant.

Models should be able to communicate and agree on design but should not exceed their purpose by adding time and complexity.

Question 19

Agile documentation vs plan-driven

Answer 19

Created with purpose. Minimise the amount of planning in favour of delivery of a working product. Replace the extensive plan-driven approach with team and client communication through user stories, regular face-to-face meetings (scrum) etc.

For requirements, it is refined throughout development with agile and replaced with artefacts like user stories, whereas with plan-driven a specific phase is allocated.

Question 20

Core agile practises

Answer 20

• Being flexible allowing for change, not linear and restricted
• Faster delivery of a working solution with more focus on developing
• Short iteration cycles (timeboxing, scrum) to allow for refinement, feedback and incremental design
• Emphasis on people and software over process
• Test Driven Development
• Regular team meetings and pair programming

Question 21

Why is reuse desirable

Answer 21

It reduces development time and cost whilst increasing flexibility by avoiding the unnecessary duplication of effort to reinvent existing solutions. It also benefits from prior test coverage making maintenance easier.

Question 22

Benefits of TDD

Answer 22

• Coverage; majority of code has been tested.
• Regression testing; changes which break previous tests can quickly be identified.
• Executable documentation; tests document code purpose and expected behaviour
• Code quality; increases code focus by implementing specific behaviour for each defined test
• Design by contract; test-first compliments DBC invariants by asserting that conditions are met
• Prevent feature creep; unnecessary features are difficult to add because they must be planned first using tests

Question 23

Limits of TDD

Answer 23

• User interface; does not apply well to interactivity, where usability testing is more suited
• Acceptance; cannot be a replacement for acceptance testing
• Large code bases and legacy components; reusing parts from a legacy system or large code base where TDD was not employed throughout can be inconsistent
• Management and time; writing many tests can slow development time and delay the delivery of features which may not be suitable for the client or management
• Rapidly changing requirements; tests must be continually rewritten as they become invalid which can be a hindrance
• Only as good as the test cases; cannot be a catch-all solution that works in all cases, as defining good test cases can be complex

Question 24

GRASP Creator

Answer 24

Allocate responsibility for object creation in order to fulfil other responsibilities.

Assigned to the class that references the class of the new object, especially if the class provides the data necessary for creation.

Low coupling as the new object is likely already linked to the creator.

E.g. bank (creator) responsible for creation of new accounts, as they are linked.

Question 25

GRASP Expert

Answer 25

Allocates a responsibility to a class which has the necessary information to fulfil it – the information expert – represented by its properties.

Used to decide which interacting objects a responsibility should be assigned. E.g. an object representing a sale through its properties could have the responsibility of calculating totals.

Maximises encapsulation – objects use their own information to fulfil a task without relying on others, therefore low coupling and high cohesion.

Question 26

coupling

Answer 26

Degree of dependence between parts of the system.

E.g. Module A depends on Module B which depends on Module C. Includes importing behaviour from another class and references.

Low coupling (independence) is favoured as it increases reusability by not requiring a chain of dependencies to implement a single feature, resulting in easier maintenance, testing and implementation.

Question 27

cohesion

Answer 27

How closely related a set of activities are within a single module.

High cohesion means a module performs one thing well, low cohesion includes many unrelated things. Therefore, high cohesion is favoured as its more predictable and easier to abstract.

Question 28

balancing coupling and cohesion

Answer 28

Low coupling and high cohesion are generally opposed. If each module only performs a single task, then complex tasks must include multiple modules, leading to high coupling.

A balanced middle-ground of independent components with a core set of responsibilities is desired, which design-by-contract (DbC) can help achieve.

Question 29

design by contract (DbC)

Answer 29

Alternative to TDD. Each operation is a contract made of pre and post conditions. Assertions are used to test the precondition is satisfied.