Software Modelling and Design Flashcards

1
Q

Movel vs design

A

Model is an abstraction of what the system will do agreed with clients. A design is an abstraction of how it will be done, agreed with developers

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Scope

A

Summarises the big picure Contains:
* Needs - problem the system solves
* Goal - What functionaility will be provided
* Business Case - how it makes money
* Stakeholder - person/group affected by system
* High-level operational concepts - How system will be used
* Success Criteria - measurements of success

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Functional Requirements

A

What the system must do, interactions between users/other systems.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Non-Functional Requirements

A

How well the system does what it does.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Design Requirements

Systems

A

How the system should be implemented.
1. implementation - use of specific tools/languages/platforms
2. interface - compatibility with other systems
3. legal - what laws to be careful of

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Specification Properties

Systems

A
  1. complete - All features of interest described only (not everything that can be done)
  2. consistent - No contradiction
  3. correct - What client wants and what developer will build
  4. unambiguous - Must have exactly 1 interpretation of each requirement
  5. Verifiable - Correctness can be tested
  6. Traceable - Requirements can be linked to their system functions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Artifact

A

A document made in system development.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Stakeholder

A

Any person/group that will be affected by the system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Actors

A

Stakeholders and systems that interact with the system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

User Story

A

Short description of a (human) actor’s expectation of a system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Scenario

A

Description of an expected use of a system. Contains actors and the flow of events to success. One particular instance

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Use Case

A

A detailed description of a user-system interaction. Achieves functional requirement(s). General expectation.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Model

A

Abstract Representation of a system, used to unify understanding about the system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Requirements Capture

A

Research exercise to work out the scope of a project. Needed as customers are not able to define project accurately. Contains forst 2 steps of project, requirements gathering and specification

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

As-Is model

A

Model describing how the system is now

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

To-Be model

A

Model describing how the system will be

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

class visibility

Class Diagram

A

private -
public +
protected #

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Class Diagram Attribute Syntax

A

visibility attribute[multiplicity ordering] : type = initialValue
multiplicity - bounds (lowerBound..upperBound)
ordering - unordered/ordered

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Class Diagram Operation Syntax

A

visibility operation(parameter list) : returnType

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Binary Association

Class Diagram

A

Association specified. Left to right or direction of solid black triangle.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

N-ary Association

Class Diagram

A

Relates more than 2 classes. Empty diamond in centre connects all classes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Aggregation Association

Class Diagram

A

Has-a relationship(1st class has 2nd class). weak lifecycle dependancy (2nd class still exists without the other). Shown with empty diamond on 1st class

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Composition Association

Class Diagram

A

Contains-a relationship(1st class contains 2nd class). Strong lifecycle dependancy (2nd class doesn’t exist without first). Shown with sold black triangle on 1st class

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Generalisation Association

Class Diagram

A

Shows subclass. Shown by arrow ending with white filled arrowhead pointing towards parent class

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Use Case Digram

A

Contains use cases and actors and connects them

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

includes

use case diagram

A

One use case always includes another, shown with labelled dotted arrow poiting to additional use case

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

extends

use case diagram

A

Shows that one use case sometimes also used. Shows with labelled dotted arrow pointing from additional use case

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

UML Structural Diagrams

A

What is contained in system. Uses object, attributes, operations and relationships.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

UML Behavioural Diagrams

A

What must happen in the system. Shows collaboration of objects and changes to object states.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Start

Activity Diagram Symbol

A

A filled in black circle. Can have multiple in a diagram.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Activity

In Activity Diagram

A

Empty Oval.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Transition

In Activity Diagram

A

Regular arrow. Change from one state to another.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Stop

In Activity Diagram

A

Filled in black circle with a ring. Multiple Allowed.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

Decision and Merge

In Activity Diagram

A

Empty diamind splitting into options

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

Fork and Join nodes

In Activity Diagram

A

Black vertical line spliting and merging into concurrent flows

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Time Event

In Activity Diagram

A

Stops flow after a period of time has elapsed. Then goes to interrupting edge. Shown by hourglass

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

Interrupting Edge

In Activity Diagram

A

Lightning bolt shaped arrow interrupts flow to different route

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

Interruptable Activity region

In Activity Diagram

A

Surrounds section in dotted line box. Allows an interrupt to happen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Object-Flow Transition

In Activity Diagram

A

A transition that goes to an object (rectangle), is done with a dashed arrow. Shows input/output from/to object.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

Swimlanes

In Activity Diagram

A

Shows which activities are done by which actors. Sections split by solid line with actor

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Activity Diagram

A

Models behavious of a system and how they are related

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

State Machine Diagram

A

Represents states of an object in a class. Used in important systems. Start and stop same as activity diagram.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

States

In State Machine Diagram

A

Rounded rectangles

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

Transitions

In State Machine Diagram

A

Arrows, always shows change of one state to another

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

Triggers

In State Machine Diagram

A

An event that occurs to the system that causes an arrow to be followed, may result in transition, or may just stay at same state

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

Sequence Diagram

A

Shows the order of events taking place. Time proceedes down the page. Constructed by vertical actors and objects of different types

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

Entity

For Sequence Diagrams

A

Shown by a circle with a horizontal line under it. The standard system object for representing system data. Cannot access non entity objects

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

Boundry

In Sequence Diagrams

A

Shown by sideways T attached to left side of circle. Objects that interface with users

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

Control

In Sequence Diagram

A

Shown by circle with an arrow in it. Acts as intermediary between boundry and entity objects

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q

Lifeline

In Sequence Diagram

A

Shown by dashed line. When an element is created and exists

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

Activation

In Sequence Diagram

A

Shown by empty vertical rectangle. Shows object executing or waiting for reply

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

Synchronous Message

Sequence Diagram

A

Shows by arrow with block black head. Requires response to continue

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

Reply/Return Message

Sequence Diagram

A

Dotted line with open head. Shows response to synchronous message

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
54
Q

Asynchronous Message

Sequence Diagram

A

Shown by arrow with open arrowhead. Doesn’t get a reply, so continues after

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
55
Q

Deletion

Sequence Diagram

A

A message can destroy an object which will be shown by a lifeline ending with a big X.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
56
Q

Found/Lost messages

Sequence Diagram

A

message originates or end in solid black circle. Means sendder or reciever is unkown

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
57
Q

Reflexive message

Sequence Diagram

A

When an object sends a message to itself

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
58
Q

Fragment

Sequence Diagram

A

Shown by box covering the affected area and the type of fragment in the top left. Indicates change in system flow

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
59
Q

Alternative fragment

Sequence Diagram

A

Shown with alt type and dotted line splitting multiple options with guards

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
60
Q

Option Combination Fragment

Sequence Diagram

A

Shown with opt type and guard. Message only happens if guard met

61
Q

Repetition/Loop Fragment

Sequence Diagram

A

Shown with loop type and guard condition. Message continues to be sent until guard not met

62
Q

Parralel Fragment

Sequence Diagram

A

Shown with par type and dotted line seperating two messages. Both messages happen at the same time

63
Q

Model Transformation

A

Improving one aspect of a model while keeping everything else the same

64
Q

Pattern

A

Reusable solution for common problem

65
Q

Anti-pattern

A

Common response to common problem but is usually ineffective

66
Q

God class

A

One class that is responsible for too much

67
Q

Association Class

A

Gives an association attributes and operations

68
Q

Sequence Diagram Structure

A

First three columns should be actor, boundry object, control object

69
Q

Fork Diagram

Sequence Diagram

A

A structure where one (usually) control object sends messages to all other object. Good when operation order and number can change.

70
Q

Stair Diagram

Sequence Diagram

A

A decentralised structure where each object only interacts with a few others and the object in control changes. Good when operations have strong connection and always done in same order

71
Q

Testing

A

Systematic and planned finding evidence of software faults (negative evidence)

72
Q

Proof

A

Provides evidence of software correctness (positive evidence)

73
Q

Formal Methods

A

Mathematical techniques for proving/disproving the correctness of a model

74
Q

Formal Method Benefits

A
  • Makes us think before coding
  • Removes ambiguities
  • Ensures system consistency
75
Q

Machine

Event-B

A

Stores variables, invarients (Limits possible values of the variable) and events

76
Q

Event

Event-B machine

A

Stores guards (The condition for the event to happen) and actions (What changes happen to the machine)

77
Q

Initialisation

Event-B

A

A special type of event that happens once when the machine is created. Sets variables to default values

78
Q

Executing an event-B machine

A

Events take no time, so no concurrency. Events are chosen arbitrarilty and run, this is repeated until all events have false guards.

79
Q

A \ B

Event B

A

All elements in A not in B

80
Q

Context

Event-B

A

Represents static part of the model. Contains constants and axioms

81
Q

Constant

Event-B context

A

Static and Final variable

82
Q

Axiom

Event-B context

A

invarient (constraint) on the constants

83
Q

Represent possible cases

Event-B

A

Done by having seperate events. e.g. use two events for if an elements is or isn’t in a set

84
Q

card(set)

event-B

A

Gives the number of elements in the set

85
Q

Types

Event-B

A

All variables and expressions have a type. A variables type is the set that it is in.

86
Q

Can sets have a type

Event-B

A

Yes, when they are a subset of another set, they have the type of the powerset of the superset. e.g. knownWords is an elements of P(allWords), so knownWords is of type P(allWords)

87
Q

Can sets have elements of different types?

Event-B

A

No, all elements in a set must be of the same type, so cannot do operations with elements of different types

88
Q

Simple Types

Event-B

A

Available by default(predefined). e.g. Z(integers) and B(booleans). OR basic types made by user but not constructed from any other type

89
Q

Constructed Types

Event-B

A

Created by the user, from another type e.g. P(T)

90
Q

Benefits of Types

Event-B

A
  • Structures specification by differentiating objects
  • Prevents errors by forcing sensible sets
  • Types can be checked by computer
91
Q

Ordered Pair

Event-B

A

Shown with x ↦ y

92
Q

Relation

Event-B

A

Shown by T↔S

93
Q

domain

Event-B

A

dom(R) - Gives the domain of relation R

94
Q

range

Event-B

A

ran(R) - gives the range of relation R

95
Q

Relational Image

Event-B

A

relation[{S}] = All elements in the domain related to any elements in the set S

96
Q

Partial Function

Event-B

A

A relation where each domain element is related to at most 1 range element. Shown by X → Y with a vertical line through the arrow indicating that not all elements in X are in the domain

97
Q

Domain Restriction

Event-B

A

Restricts relation R to only have domain S. Shown by S empty left triangle R

98
Q

Domain Subtraction

Event-B

A

Restricts R to only have domain with elements not is S. Shown by S line in left triangle R

99
Q

Range Subtraction

Event-B

A

Restricts R to only have range with elements not is S. Shown by R line in right triangle S

100
Q

Range Restriction

Event-B

A

Restricts relation R to only have range S. Shown by R empty right triangle S

101
Q

Function Overriding

Event-B

A

Replaces pairs with same first element with a different second element. Shown by f left triangle right shifted line g, shows function f overridden by function g

102
Q

Total Function

Event-B

A

Shown by X → Y. Every element in X is in the domain of the function

103
Q

Relational Inverse

Event-B

A

Swaps the order of the elements in all ordered pairs. Shown by R∼

104
Q

Relational Composition

Event-B

A

Combines two relations such that it forms a new relation with domain being a subset of the first relation and range being a subset of the final relation. Shown by Q;R

105
Q

Injective Function

Event-B

A

one to one. Shown by A ↣ B

106
Q

Surjective Function

Event-B

A

All elements if B in range. Shown by A ↠ B

107
Q

primary carrier set

Event-B

A

System is responsible for managing these sets, e.g. creation deletion, machine defines them in lower case

108
Q

secondary carrier set

Event-B

A

Attributes of primary carrier sets, remains in upper case defined in context

109
Q

Abstraction

Event-B

A

Focus on key purpose of system and ignore how the purpose is achieved

110
Q

Refinement

Event-B

A

Opposite of abstraction. Adds functionality or explains how existing purpose achieved

111
Q

Extension Refinment

Event-B

A

Type of refinement where:
* Variables and invarients added
* Existing events extended to change extra variables
* New events for extra variables
* Existing variables are not changed

112
Q

Lists

Event-B

A

Modelled by injective function betwen elements and position of elements

113
Q

Queues

Event-B

A

Modelled by list with new elements having the highest position. Element with the lowest position is removed

114
Q

Stack

Event-B

A

Modelled by list with new elements having the highest position. Element with the highest position is removed

115
Q

Collection of Lists

Event-B

A

Modelled by function from elements to lists in addition to function from element to position

116
Q

Collection of queues

Event-B

A

Modelled as a function from elements to queues. Create an invarient to ensure that two different elements in the same queue cannot have the same position

117
Q

partition

Event-B

A

An operator that splits a set into disjoint subsets. i.e. elements are in exactly 1 of the partitions. Done with partition(parentSet, subset1,…)

118
Q

Set Comprehension

Event-B

A

A method of getting a subset of a set with specific restrictions. Written with { x | x ∈ S ∧ C } where x is an element in set S and C is a condition. This gives a set of elements that are in set S and satisfy condition C

119
Q

Requirements Validation

Event-B

A

The extent that the requirements meet the needs of the stakeholders

120
Q

Model Validation

Event-B

A

The extent to which the model captures the requirements

121
Q

Model Verification

Event-B

A

The extent that a model correctly maintains invarients and refines another model

122
Q

Proof Obligations

Event-B

A

Mathematical Theorums derived from a model. Used to verify property of models. In event-B they are sequents

123
Q

Invariant Establishment

Event-B

A

The case that when the variables in a system are initialised, the invariants are satisfied

124
Q

Invarient Preservation

Event-B

A

The case that when any event occuring preserves the satisfaction of the invarient

125
Q

Sequent

Event-B

A

Consists of hypotheses(H) and a goal(G) written H ⊢ G. It is valid if G follows from H.

126
Q

Bound Variables

Event-B

A

Variables that are defined by a quantifier (e.g. ∀) are bound so ∀n would mean n is bound. Free variables are not bound

127
Q

Substitution

Event-B

A

The act of replacing all free variables in a expression. e.g. the substitution n:=7 applied to expression 0<n ∧ n≤10 would be written as ( 0<n ∧ n≤10 ) [n:=7] and would lead to 0<7 ∧ 7≤10. Multiple substitutions can be done with comma seperated values e.g. (l<n ∧ n≤m) [ l,m,n:=0,10,7 ]

128
Q

Test to Pass

A

Tests that the program works as expected when testing main use cases

129
Q

Test to Fail

A

Tests that the program works when using non-typical inputs

130
Q

Test Case

A

Contains the inputs and expected outputs

131
Q

System Failure

Testing

A

An event where a system does not behave as expected

132
Q

System Error

Testing

A

An incorrect system state that may lead to a system failure

133
Q

System Fault

Testing

A

A component of the system that may lead to a system error

134
Q

Human Error

Testing

A

An action that can create a system fault

135
Q

Output Sets

Testing Venn Diagram

A
  • Specified Outputs - Outputs that are expected
  • Implemented Outputs - Outputs that the program produces
  • Test Cases - outputs that are tested for
136
Q

Test Coverage

Testing Venn Diagrams

A

The test cases should cover all specified outputs, meaning all expected outputs are tested. Eventually test cases, specified outputs and implemented outputs should be equal when complete.

137
Q

Equivalence Class Testing (ECT)

A

Splitting the inputs into different equivalence classes and testing 1 element of each equivalence class. Commonly split by output, i.e. 1 equivalence class for each output

138
Q

Weak

multi input ECT

A

Test 1 value from each equivalence class of one input variable

139
Q

Strong

multi input ECT

A

Take 1 value of each possible combination of equivalence classes from the input variables

140
Q

Normal

multi input ECT

A

Only test values inside of the valid input range

141
Q

Robust

multi input ECT

A

Test values inside the valid input range and outside

142
Q

Patterns Benefits

A
  • Can implements new/updated requirements without large code change
  • Minimises time to onboard team members
  • Maximises code reusage
143
Q

Types

Design Patterns

A
  • Structural - How to assemble objects/classes into larger strucutures e.g. adapter
  • Creational - How objects are created e.g. factory
  • Behavioral -Defines how object communicate with each other e.g. observer
144
Q

Composite

Design Patterns

A

Objects are stores in a tree structure. Both leaf and composite (non-leaf) objects implements one interface allowing for the all to be worked with in the same way. (structural)

145
Q

Adapter

Design Patterns

A

Allows for the use of extrernal code not compatible with existing classes. The adapter class is a subclass of the class to convert the incompatible class to. The adapter class then overrides the methods to allow for 3rd party methods to be called, while the rest of the program treats the class the same.

146
Q

Bridge

Design Patterns

A

Allows for each object to have multiple properties. Splits properties into two different trees, connected by storing an instance of the root of the second tree. These trees can then be developed seperately.

147
Q

Decorator

Design Patterns

A

Allows for objects to be given any permutation of extra features, each one coming from a seperate decorator object. At runtime any number of decorators with the same interface as the component (initial object) wrap the component object.

148
Q

Observer

Design Patterns

A

Allows for notifying many objects of a change without their knowledge of each other. The subject has a list of observers that are notified when a change happens.

149
Q

Factory

Design Patterns

A

Allows for the creation of objects without the client code’s knowledge of it. Create an abstract super class that contains a method for creating objects. The subclasses then implement this method.