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
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
3
Q
Functional Requirements
A
What the system must do, interactions between users/other systems.
4
Q
Non-Functional Requirements
A
How well the system does what it does.
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
6
Q
Specification Properties
Systems
A
- complete - All features of interest described only (not everything that can be done)
- consistent - No contradiction
- correct - What client wants and what developer will build
- unambiguous - Must have exactly 1 interpretation of each requirement
- Verifiable - Correctness can be tested
- Traceable - Requirements can be linked to their system functions
7
Q
Artifact
A
A document made in system development.
8
Q
Stakeholder
A
Any person/group that will be affected by the system
9
Q
Actors
A
Stakeholders and systems that interact with the system
10
Q
User Story
A
Short description of a (human) actor’s expectation of a system
11
Q
Scenario
A
Description of an expected use of a system. Contains actors and the flow of events to success. One particular instance
12
Q
Use Case
A
A detailed description of a user-system interaction. Achieves functional requirement(s). General expectation.
13
Q
Model
A
Abstract Representation of a system, used to unify understanding about the system
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
15
Q
As-Is model
A
Model describing how the system is now
16
Q
To-Be model
A
Model describing how the system will be
17
Q
class visibility
Class Diagram
A
private -
public +
protected #
18
Q
Class Diagram Attribute Syntax
A
visibility attribute[multiplicity ordering] : type = initialValue
multiplicity - bounds (lowerBound..upperBound)
ordering - unordered/ordered
19
Q
Class Diagram Operation Syntax
A
visibility operation(parameter list) : returnType
20
Q
Binary Association
Class Diagram
A
Association specified. Left to right or direction of solid black triangle.
21
Q
N-ary Association
Class Diagram
A
Relates more than 2 classes. Empty diamond in centre connects all classes
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
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
24
Q
Generalisation Association
Class Diagram
A
Shows subclass. Shown by arrow ending with white filled arrowhead pointing towards parent class
25
Use Case Digram
Contains use cases and actors and connects them
26
includes
| use case diagram
One use case always includes another, shown with labelled dotted arrow poiting to additional use case
27
extends
| use case diagram
Shows that one use case sometimes also used. Shows with labelled dotted arrow pointing from additional use case
28
UML Structural Diagrams
What is contained in system. Uses object, attributes, operations and relationships.
29
UML Behavioural Diagrams
What must happen in the system. Shows collaboration of objects and changes to object states.
30
Start
| Activity Diagram Symbol
A filled in black circle. Can have multiple in a diagram.
31
Activity
| In Activity Diagram
Empty Oval.
32
Transition
| In Activity Diagram
Regular arrow. Change from one state to another.
33
Stop
| In Activity Diagram
Filled in black circle with a ring. Multiple Allowed.
34
Decision and Merge
| In Activity Diagram
Empty diamind splitting into options
35
Fork and Join nodes
| In Activity Diagram
Black vertical line spliting and merging into concurrent flows
36
Time Event
| In Activity Diagram
Stops flow after a period of time has elapsed. Then goes to interrupting edge. Shown by hourglass
37
Interrupting Edge
| In Activity Diagram
Lightning bolt shaped arrow interrupts flow to different route
38
Interruptable Activity region
| In Activity Diagram
Surrounds section in dotted line box. Allows an interrupt to happen
39
Object-Flow Transition
| In Activity Diagram
A transition that goes to an object (rectangle), is done with a dashed arrow. Shows input/output from/to object.
40
Swimlanes
| In Activity Diagram
Shows which activities are done by which actors. Sections split by solid line with actor
41
Activity Diagram
Models behavious of a system and how they are related
42
State Machine Diagram
Represents states of an object in a class. Used in important systems. Start and stop same as activity diagram.
43
States
| In State Machine Diagram
Rounded rectangles
44
Transitions
| In State Machine Diagram
Arrows, always shows change of one state to another
45
Triggers
| In State Machine Diagram
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
46
Sequence Diagram
Shows the order of events taking place. Time proceedes down the page. Constructed by vertical actors and objects of different types
47
Entity
| For Sequence Diagrams
Shown by a circle with a horizontal line under it. The standard system object for representing system data. Cannot access non entity objects
48
Boundry
| In Sequence Diagrams
Shown by sideways T attached to left side of circle. Objects that interface with users
49
Control
| In Sequence Diagram
Shown by circle with an arrow in it. Acts as intermediary between boundry and entity objects
50
Lifeline
| In Sequence Diagram
Shown by dashed line. When an element is created and exists
51
Activation
| In Sequence Diagram
Shown by empty vertical rectangle. Shows object executing or waiting for reply
52
Synchronous Message
| Sequence Diagram
Shows by arrow with block black head. Requires response to continue
53
Reply/Return Message
| Sequence Diagram
Dotted line with open head. Shows response to synchronous message
54
Asynchronous Message
| Sequence Diagram
Shown by arrow with open arrowhead. Doesn't get a reply, so continues after
55
Deletion
| Sequence Diagram
A message can destroy an object which will be shown by a lifeline ending with a big X.
56
Found/Lost messages
| Sequence Diagram
message originates or end in solid black circle. Means sendder or reciever is unkown
57
Reflexive message
| Sequence Diagram
When an object sends a message to itself
58
Fragment
| Sequence Diagram
Shown by box covering the affected area and the type of fragment in the top left. Indicates change in system flow
59
Alternative fragment
| Sequence Diagram
Shown with alt type and dotted line splitting multiple options with guards
60
Option Combination Fragment
| Sequence Diagram
Shown with opt type and guard. Message only happens if guard met
61
Repetition/Loop Fragment
| Sequence Diagram
Shown with loop type and guard condition. Message continues to be sent until guard not met
62
Parralel Fragment
| Sequence Diagram
Shown with par type and dotted line seperating two messages. Both messages happen at the same time
63
Model Transformation
Improving one aspect of a model while keeping everything else the same
64
Pattern
Reusable solution for common problem
65
Anti-pattern
Common response to common problem but is usually ineffective
66
God class
One class that is responsible for too much
67
Association Class
Gives an association attributes and operations
68
Sequence Diagram Structure
First three columns should be actor, boundry object, control object
69
Fork Diagram
| Sequence Diagram
A structure where one (usually) control object sends messages to all other object. Good when operation order and number can change.
70
Stair Diagram
| Sequence Diagram
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
Testing
Systematic and planned finding evidence of software faults (negative evidence)
72
Proof
Provides evidence of software correctness (positive evidence)
73
Formal Methods
Mathematical techniques for proving/disproving the correctness of a model
74
Formal Method Benefits
* Makes us think before coding
* Removes ambiguities
* Ensures system consistency
75
Machine
| Event-B
Stores variables, invarients (Limits possible values of the variable) and events
76
Event
| Event-B machine
Stores guards (The condition for the event to happen) and actions (What changes happen to the machine)
77
Initialisation
| Event-B
A special type of event that happens once when the machine is created. Sets variables to default values
78
Executing an event-B machine
Events take no time, so no concurrency. Events are chosen arbitrarilty and run, this is repeated until all events have false guards.
79
A \ B
| Event B
All elements in A not in B
80
Context
| Event-B
Represents static part of the model. Contains constants and axioms
81
Constant
| Event-B context
Static and Final variable
82
Axiom
| Event-B context
invarient (constraint) on the constants
83
Represent possible cases
| Event-B
Done by having seperate events. e.g. use two events for if an elements is or isn't in a set
84
card(set)
| event-B
Gives the number of elements in the set
85
Types
| Event-B
All variables and expressions have a type. A variables type is the set that it is in.
86
Can sets have a type
| Event-B
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
Can sets have elements of different types?
| Event-B
No, all elements in a set must be of the same type, so cannot do operations with elements of different types
88
Simple Types
| Event-B
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
Constructed Types
| Event-B
Created by the user, from another type e.g. P(T)
90
Benefits of Types
| Event-B
* Structures specification by differentiating objects
* Prevents errors by forcing sensible sets
* Types can be checked by computer
91
Ordered Pair
| Event-B
Shown with x ↦ y
92
Relation
| Event-B
Shown by T↔S
93
domain
| Event-B
dom(R) - Gives the domain of relation R
94
range
| Event-B
ran(R) - gives the range of relation R
95
Relational Image
| Event-B
relation[{S}] = All elements in the domain related to any elements in the set S
96
Partial Function
| Event-B
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
Domain Restriction
| Event-B
Restricts relation R to only have domain S. Shown by S empty left triangle R
98
Domain Subtraction
| Event-B
Restricts R to only have domain with elements not is S. Shown by S line in left triangle R
99
Range Subtraction
| Event-B
Restricts R to only have range with elements not is S. Shown by R line in right triangle S
100
Range Restriction
| Event-B
Restricts relation R to only have range S. Shown by R empty right triangle S
101
Function Overriding
| Event-B
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
Total Function
| Event-B
Shown by X → Y. Every element in X is in the domain of the function
103
Relational Inverse
| Event-B
Swaps the order of the elements in all ordered pairs. Shown by R∼
104
Relational Composition
| Event-B
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
Injective Function
| Event-B
one to one. Shown by A ↣ B
106
Surjective Function
| Event-B
All elements if B in range. Shown by A ↠ B
107
primary carrier set
| Event-B
System is responsible for managing these sets, e.g. creation deletion, machine defines them in lower case
108
secondary carrier set
| Event-B
Attributes of primary carrier sets, remains in upper case defined in context
109
Abstraction
| Event-B
Focus on key purpose of system and ignore how the purpose is achieved
110
Refinement
| Event-B
Opposite of abstraction. Adds functionality or explains how existing purpose achieved
111
Extension Refinment
| Event-B
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
Lists
| Event-B
Modelled by injective function betwen elements and position of elements
113
Queues
| Event-B
Modelled by list with new elements having the highest position. Element with the lowest position is removed
114
Stack
| Event-B
Modelled by list with new elements having the highest position. Element with the highest position is removed
115
Collection of Lists
| Event-B
Modelled by function from elements to lists in addition to function from element to position
116
Collection of queues
| Event-B
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
partition
| Event-B
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
Set Comprehension
| Event-B
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
Requirements Validation
| Event-B
The extent that the requirements meet the needs of the stakeholders
120
Model Validation
| Event-B
The extent to which the model captures the requirements
121
Model Verification
| Event-B
The extent that a model correctly maintains invarients and refines another model
122
Proof Obligations
| Event-B
Mathematical Theorums derived from a model. Used to verify property of models. In event-B they are sequents
123
Invariant Establishment
| Event-B
The case that when the variables in a system are initialised, the invariants are satisfied
124
Invarient Preservation
| Event-B
The case that when any event occuring preserves the satisfaction of the invarient
125
Sequent
| Event-B
Consists of hypotheses(H) and a goal(G) written H ⊢ G. It is valid if G follows from H.
126
Bound Variables
| Event-B
Variables that are defined by a quantifier (e.g. ∀) are bound so ∀n would mean n is bound. Free variables are not bound
127
Substitution
| Event-B
The act of replacing all free variables in a expression. e.g. the substitution n:=7 applied to expression 0\
128
Test to Pass
Tests that the program works as expected when testing main use cases
129
Test to Fail
Tests that the program works when using non-typical inputs
130
Test Case
Contains the inputs and expected outputs
131
System Failure
| Testing
An event where a system does not behave as expected
132
System Error
| Testing
An incorrect system state that may lead to a system failure
133
System Fault
| Testing
A component of the system that may lead to a system error
134
Human Error
| Testing
An action that can create a system fault
135
Output Sets
| Testing Venn Diagram
* Specified Outputs - Outputs that are expected
* Implemented Outputs - Outputs that the program produces
* Test Cases - outputs that are tested for
136
Test Coverage
| Testing Venn Diagrams
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
Equivalence Class Testing (ECT)
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
Weak
| multi input ECT
Test 1 value from each equivalence class of one input variable
139
Strong
| multi input ECT
Take 1 value of each possible combination of equivalence classes from the input variables
140
Normal
| multi input ECT
Only test values inside of the valid input range
141
Robust
| multi input ECT
Test values inside the valid input range and outside
142
Patterns Benefits
* Can implements new/updated requirements without large code change
* Minimises time to onboard team members
* Maximises code reusage
143
Types
| Design Patterns
* 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
Composite
| Design Patterns
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
Adapter
| Design Patterns
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
Bridge
| Design Patterns
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
Decorator
| Design Patterns
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
Observer
| Design Patterns
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
Factory
| Design Patterns
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.
