TM354 Flashcards Preview

Software Engineering > TM354 > Flashcards

Flashcards in TM354 Deck (145)
Loading flashcards...
1
Q

Causes of software errors [3]

A

Malleability
Complexity
Size

2
Q

A good software system is… [6]

A
Useful
Usable
Reliable
Available
Flexible
Affordable
3
Q

Legacy systems are… [8]

A

Old
Large
Developed using outdated technologies
Implemented in old programming languages
Critical to the business
Changed a number of times since inception
Difficult to understand due to lack of documentation or experience

Therefore difficult to maintain

4
Q

A module should… [4]

A

Have low coupling, high cohesion, a well-defined interface and represent a good abstraction

5
Q

Reuse can improve development in terms of… [4]

A

Maintainability
Cost
Delivery time
Quality

6
Q

Development activities [5]

A
Domain modelling
Requirements elicitation + analysis
Design
Implementation
Testing
7
Q

Traceability

A

Tracing the history of each requirement from its origin in the problem domain to its fulfillment in the final system.

8
Q

What will determine the level of traceability?

A

The chosen development process

9
Q

The UP advocates which development practices?

A

Timeboxing
Big risks up front
Early architecture
User involvement

10
Q

The UP stages [4]

A

Inception
Elaboration
Construction
Transition

11
Q

User stories should be… [6]

A
Independent
Negotiable
Valuable to users
Estimable
Testable
Small
12
Q

Difference between business functional requirement and technical solution requirement

A

Business functional requirement: system authenticates the users.

Technical solution requirement: authenticate users via a password

13
Q

How to gather Software Functional Requirements

A
Business processes/events ->
Use cases ->
Scenarios ->
Functional tasks ->
Software functional requirements
14
Q

Non-functional Requirement Types [8]

A
Look and feel
Usability and humanity
Performance
Operational and environmental
Maintainability and support
Cultural
Legal
Security
15
Q

Performance Fit Criteria [6]

A
Speed
Capacity
Safety
Accuracy
Reliability
Availability
16
Q

Seucirty Fit Criteria [5]

A
Access
Privacy
Integrity
Audit
Immunity
17
Q

Function and non-functional requirements must have ______ so that they are testable

A

Fit criteria

18
Q

Volere template sections [5]

A
  1. Project drivers
  2. Project constraints
  3. Functional requirements
  4. Non-functional requirements
  5. Project issues
19
Q

Main concepts in a business domain [4]

A

Resources
Processes
Rules
Goals

20
Q

Examples of business processes and business rules

A

Business process: renting a car

Business rule: lowest mileage car always allocated

21
Q

Use cases are used to capture ______ [1]

A

Functional requirements

22
Q

Scenarios are used to ________ [1]

A

Illustrate the different ways a use case can unfold

23
Q

Use case description [8]

A
Identifier + Name
Initiator
Goal
Precondition
Postcondition
Assumptions
Main success scenario
24
Q

Each step in a use case may correspond to _______

A

One or more software functional requirements

25
Q

Each software functional requirements should ______ [3]

A

Be unambigious
State what the system should do (not how)
Have a fit criterion

26
Q

Use cases help to _______ [5]

A
Capture requirements
Capture software requirements
Plan development
Validate the system
Narrow down architecture
27
Q

Use case descriptions help to _________ each use case [4]

A

Understand the complexity
Determine which actors are involved
Understand the level of risk
Estimate effort to implement

28
Q

Use case diagrams:
What are Inclusion and Extension?
Are they conditional or unconditional?

A

Inclusion: Two or more use cases have overlapping functionality that can be factored out as a separate use case. Unconditional.

Extension: A use case has alternative scenarios that demand a variation on the original use case. Conditional.

29
Q

Use case modelling steps [5]

A
  1. Identify the actors
  2. Analyse the behaviour
  3. Find common behaviour and variations
  4. Draw the model to show the actors, use cases and their relationships
  5. Annotate as you learn more
30
Q

You should stop prototyping when _______ [1]

A

When you are not generating new requirements

31
Q

Difference between use case and user story

A

A use case describes a business process

A user story is a single, small piece of user functionality

32
Q

Conceptual class attributes represent _____ [1]

A

Terms from the domain expert’s vocabulary

33
Q

Generalisation, specialisation and interfaces are not required during _______

A

Domain modelling

34
Q

Express the constraint that a library member’s current loans and past loans must not overlap

A

context LibraryMember inv:

(pastLoans -> intersection(currentLoans)) -> isEmpty()

35
Q

Express the constraint that the room that a guest is occupying be part of the hotel that the guest is linked to

A

context Guest inv:

self.currentRoom.notEmpty() implies self.currentRoom = self.hotel

36
Q

OCL logical operators [5]

A
and
or
xor
not
implies
37
Q

OCL operations [14]

A

c1 -> isEmpty()
c1 -> notEmpty()
c1 -> count()

c1 -> includes(object)
c1 -> includesAll(c2)
c1 -> any(expression)
c1 -> select(expression)
c1 -> forAll(expression)
c1 -> exists(expression)
s1 = s2 (contains same elements)
s1 -> untion(s2)
s1 -> intersection(s2)
s1 - s2
s2 - s1
38
Q

DbC helps to relate the requirements to the code by ______ [1]

A

Providing traceability

39
Q

A subclass must neither ______ the precondition nor ______ the postcondition of its superclass

A

strengthen, weaken

40
Q

Postconditions consist of ______ [3]

A

Creating/removing objects
Creating/removing links
Modifying attributes

41
Q

Dynamic modelling helps to decide ______ [1]

A

Which operations should be allocated to which classes

42
Q

Communication diagrams emphasise _______.

Sequence diagrams emphasise _________.

A

Communication diagrams emphasise the sending and receiving of messages.

Sequence diagrams emphasise the ordering of messages.

43
Q

The responsibility for creating objects should be given to the class that ________ [4]

A

Aggregates or contains the objects
Uses the object
Maintains the object
Provides initialisation information

44
Q

When a responsibility involves consolidating information that is distributed among objects, it should be assigned to _______ [1]

A

The class that has the most information to fulfill it

45
Q

When can you update the navigability of associations?

A

Once you have interaction diagrams

46
Q

The Law of Demeter

An object can send messages to _______ [4]

A

Objects sent as parameters to the current method
New objects that the object has created in the current method
Objects that it has direct links to (its immediate neighbours)
Itself

47
Q

Sequence diagram loop syntax

A
  • [i:= 1..12] printReportForMonth()
48
Q

Difference between defensive programming and DbC

A

Defensive programming: always check preconditions before processing.

DbC: Assume that precondition has been met

49
Q

What is the One Central Class strategy?
Advantages [2]
Disadvantages [1]

A

All UI messages are sent to a single object.
+ Low coupling
+ Good traceability
- Central class can become overloaded

50
Q

What is the Actor Classes strategy?
Advantage [1]
Disadvantages [2]

A

All UI messages are sent to objects that correspond to the real-world initiator.
+ System corresponds to real world
- Traceability is more difficult
- A use case may have more than one initiator

51
Q

What is the Use Cases as Classes strategy?
Advantage [1]
Disadvantage [1]

A

All UI messages are sent to use case objects, which each have a run() method. e.g. checkerIn.run()
+ Increases usability as changes in workflows/business rules are localised to one class
- Increased coupling as UI communicates with several classes

52
Q

What are state machine diagrams represent?

What are they used for?

A

They represent the life histories of objects.

They are used to model software objects receiving messages or real-world objects responding to events

53
Q

In a state diagram, if an event has consequences beyond a state change these can be modeled as _______ [1]

A

Actions

54
Q

State machine actions should only refer to things that the object knows about, including ________ [4]

A

Its attributes
Its operations
Its links
The parameters of the message it receives

55
Q

What are entry/exit events on a state machine?

What is their syntax?

A

Events that take place each time there is a transition into or out of a state, including self-transitions.

entry / setOccupant(aGuest)
exit / removeOccupant()

56
Q

How can you avoid triggering entry/exit events on a state machine?
What is the syntax?

A

An internal transition does not involve a change of state.

hotelLimitChanged() / resetAvailableRooms()

57
Q

When deciding which attributes to include in a state diagram you should consider _______ [1]

A

Each attribute’s frequency of change

58
Q

In a state diagram, transitions have _______ [5]

A
Source state
Target state
Event trigger (message)
Action / action sequence
Guard
59
Q

Reasons to partition a software system [3]

A

To manage size and complexity
For information hiding
For logical decomposition

60
Q

Can packages have associations?

A

No, but a class in one package can have an association with a class in another

61
Q

In a package diagram, what is the difference between <> and <>?

A

<> combines the namespaces so that elements in the imported package can be accessed as if in the same package.

<> keeps the namespaces separate, so that identifiers have to be qualified (e.g. Accounts::Transaction).

62
Q

UML visibility symbols [4]

A

+ public
- private
# protected
~ package

63
Q

What is software architecture?

A

Software architecture is the overall structure of the system, in terms of software components and their relationships.

64
Q

What is the relationship between architecture and requirements

A

They should be developed in parallel (twin peaks)

65
Q

What are the Architecturally Significant Requirements? [4]

A

Core features
Quality attributes
Constraints
Application environment

66
Q

What are the architectural views [3]

A

Logical view
Process view
Deployment view

67
Q

What does an architectural view represent?

A

A representation of the system that highlights the concerns of a stakeholder group

68
Q

Examples of reuse in development [5]

A
Requirements patterns
Analysis patterns
Architecture
Design patterns
Idioms
69
Q

Architectural styles [9]

A
Client-server
Call-return
Layered
Peer-to-peer
Data flow (pipes and filters)
Data-centred
Independent components
Service Oriented
Notification
70
Q

Client-server architecture: components/connectors

A

Programs

Requests

71
Q

Call-return architecture: components/connectors

A

Programs/objects

Messages

72
Q

Layered architecture: components/connectors

A

Services

Service calls

73
Q

Peer-to-peer architecture: components/connectors

A

Programs (peers)

Connections

74
Q

Data-flow architecture: components/connectors

A

Programs/objects

Services that pipe the data

75
Q

Data-centred architecture: components/connectors

A

Database server/client

Database queries

76
Q

Independent components architecture: components/connectors

A

Components

Message exchange protocols

77
Q

Service-oriented architecture: components/connectors

A

Service providers/consumers

Requests/responses

78
Q

Notification architecture: components/connectors

A

Publishers/subscribers

Procedure calls/messages

79
Q

What are frameworks?

A

Frameworks consist of a reusable architecture and a set of components that can be slotted into it

80
Q

What is a product line?

A

A domain-specific framework incorporating specialist knowledge about a group of closely related systems

81
Q

Types of design pattern [3]

A

Creational patterns
Structural patterns
Behavioural patterns

82
Q

When should the Singleton design pattern be used?

A

When there should only be one instance of a particular class (e.g. one central class strategy)

83
Q

When should the Factory design pattern be used?

A

When object creation and initialisation is complex, changeable or uses information the client may not know

84
Q

When should the Factory Method design pattern be used?

A

When the actual classes should be determined at run-time (e.g. config file, late binding)

85
Q

Component-based development (CBD) aims to ______ [1]

A

Assemble systems from reusable components

86
Q

Components have two kinds of interface. What are they and what do they represent?

A

Required and provided.

They represent the set of assumptions that components make about each other

87
Q

Components should ______ [3].

They may include ______ [1].

A

Encapsulate data and operations
Be fully documented and thoroughly tested
Be known to their clients only through their interface
May include NFRs in their specification

88
Q

Components:
Advantages [4]
Disadvantages [3]

A

Faster and cheaper development
More reliable and maintainable

May require adapters
May require plumbing
May be inflexible

89
Q

The Assume-Guarantee contract between components will include _____ [4]

A
  1. Pre/Postconditions of all operations in the provided interface.
  2. The invariants that apply to any publicly visible properties
  3. The required interface and its assumptions
  4. Any assumptions about the environment in which it will operate
90
Q

Software that was not designed as a component can be integrated into a component-based system by _______

A

Wrapping it with an adapter that providers appropriate interfaces

91
Q

What is a service?

A

A service is an abstract description of some business functionality. It is what is provided by a component, but the component itself has been abstracted away

92
Q

How is a service different from a component? [6]

A
Platform independent
Language independent
Location independent
Centralised
Autonomous
Can be stateless
93
Q

Service types [3] and examples

A

Utility - currency conversion
Business - check membership application
Coordination - process membership application

94
Q

SOA development stages [5]

A
  1. Design workflow
  2. Find services
  3. Select services
  4. Orchestrate
  5. Test
95
Q

Advantages of services [7]

A
Agile and flexible
Less duplication
Legacy integration
3rd party service integration
Language independence
Platform independence
Location independence
96
Q

Quality attribute scenarios - six part model [6]

A
Source
Stimulus
Artefact
Environment
Response
Measure
97
Q

Quality attribute scenarios - performance values

A

Source: internal/external
Stimulus: periodic/sporadic/bursty/stochastic events
Artefact: system
Environment: normal/overloaded
Response: process stimuli/change level of service
Measure: latency/deadline/throughput/jitter/miss rate/data loss

98
Q

Quality attribute scenarios - usability values

A

Source: end users

Stimulus: user wants to learn system features/use system efficiently/minimise impact of errors/feel comfortable

Artefact: system

Environment: setting preferences/using system

Response: supporting learning/supporting efficiency/allowing adaptation/minimising impact of errors/making user comfortable

Measure: task time/no. of errors/no. of problems solved/success rate/user satisfaction/time taken/data lost

99
Q

Performance tactics: manage demand [3]

A

Reduce frequency of events
Limit demand
Increase efficiency

100
Q

Performance tactics: manage resources [3]

A

Increase resources
Reduce bottenecks
Exploit concurrency

101
Q

Performance tactics: arbitrate resources [1]

A

Schedule resources

102
Q

Performance tactics [3]

A

Manage demand
Manage resources
Arbitrate resources

103
Q

Flexibility tactics [4]

A

Low coupling
High cohension
Keep modules small
Late binding

104
Q

Assertion mechanisms allow pre/postconditions to _______ [4]

A

Be checked at run-time
Be turned on/off globally
Be separated from program logic
Indicate their breach

105
Q

DbC uses _______ [1].

TDD uses _______[1].

A

DbC uses invariants

TDD uses test cases

106
Q

How high should quality be, and why?

A

Sufficiently high, so as to be useful and affordable

107
Q

Software Quality Factor Categories [3]

A

Product operation requirements
Product revision requirements
Product transition requirements

108
Q

Software Quality Factors - Product operation [5]

A
Correctness
Reliability
Efficiency
Integrity
Usability
109
Q

Software Quality Factors - Product revision [3]

A

Maintainability
Flexibility
Testability

110
Q

Software Quality Factors - Product transition [3]

A

Portability
Reusability
Interoperability

111
Q

What is the difference between validation and verification?

A

Verification assumes the requirements are correct and aims to ensure that the system description is self-consistent and that development meets the specification.

Validation focuses on meeting the needs of the stakeholders without assuming that the specification is correct

112
Q

What is analytical completeness?

A

Ensuring the completeness of all requirements that have fit criteria

113
Q

Test-driver Development process [6]

A
  1. Decide on a code increment
  2. Decide on a test
  3. Write the test
  4. Run all test (expecting failure)
  5. Write the code
  6. Re-run all tests
114
Q

Benefits of test-driven development [7]

A
Test coverage
Regression testing and early discovery of errors
Executable documentation
Beneficial effect on design
Complements DbC
Promotes good code quality
Inhibition of 'featuritis'
115
Q

When might TDD not be applicable? [5]

A
Applications with databases
Multithreaded systems
Legacy systems/large components
Highly changeable requirements
User-interfaces
116
Q

What does TDD not replace? [3]

A

User/usability testing
Acceptance testing
Integration testing

117
Q

DbC method structure [4]

A

method heading
assert preconditions
method body
assert postconditions

118
Q

Types of testing [6] (verification/validation)

A
Unit (verification)
Integration (verification)
Regression (verification)
System (validation)
Usability (validation)
Acceptance (validation)
119
Q

Functions of testing [2]

A

Improving quality by removing errors

Improving confidence by estimating quality

120
Q

TDD and DbC focus on what type of testing?

A

Black-box testing

121
Q

Black-box testing process

A
  1. Determine the input space
  2. Partition the input space into subdomains
  3. Perform boundary testing on each subdomain
122
Q

White-box testing process

A

Identify and test each path through the code

123
Q

Disadvantages of black-box testing [2]

A

Tends to suffer from poor coverage

Cannot account for internal state of objects

124
Q

Disadvantage of white-box testing 1]

A

Does not reveal missing or incorrect requirements

125
Q

Software complexity metrics [7]

A
Lines of code
Cyclomatic-complexity
Depth of inheritance tree
Coupling between objects
Number of children
Response for a class
Weighted methods for a class
126
Q

The logical view includes ________ [3]

A

Structural models
Behavioural models
Package diagrams

127
Q

Visibility modifiers [4]

A

Public: visible to all classes
Private: visible only to itself
Protected: visible to itself and subclasses
Package: (default) visible to classes in the same package

128
Q

Primary Software Quality Attributes [4]

A

Correctness
Usability
Integrity
Maintainability

129
Q

Design patterns [8]

A
Adapter
MVC
Observer
Factory
Factory Method
Singleton
Decorator
Facade
130
Q

Writing tests for an operation involves _______ [3]

A

Setting up a fixture
Invoking the operation
Checking the postconditions

131
Q

Specifying operations involves _________ [5]

A
  1. Matching the signature and return type
  2. Writing tests
  3. Running tests (which fail)
  4. Writing code (fulfilling contract)
  5. Re-running tests
132
Q

Compare agile and plan-driven development in terms of requirements change

A

Agile treats it as inevitable and starts building quickly to discover requirements. Plan-driven attempts to avoid it by having complete requirements before implementing them.

133
Q

Why is estimation importing in agile development?

A

Being able to plan increments

Being able to deal with requirements changes

134
Q

How does requirements documentation differ between agile and plan-driven development?

A

Agile: requirements documentation is kept to a minimum, is only used to the extent that it helps communication and is often discarded.

Plan-driven: requirements documentation should be comprehensive and forms a contract between developers and customers

135
Q

What does the logical view of a system describe?

A

The system’s main functional elements and their interactions (i.e. the services the system must provide users)

136
Q

How does TDD benefit design? [2]

A

Testability of design is enforced by the need to write tests before implementing requirements.

Designs that rely on overly complex code will be identified when attempting to write tests for them, and can be reconsidered early.

137
Q

What problem does the Adapter pattern solve?

A

A client that cannot use a component because it expects a different interface than the one provided.

138
Q

What does it mean for a service to be stateless?

A

The service responds to each request as a ‘one-off’, without retaining any memory of previous requests.

139
Q

How can agile development help achieve a good software system? [2]

A

Adapting to change requirements, leading to a flexible and useful system.

Delivery on time, leading to an available system

140
Q

Benefits of using a standard template for requirements capture [4]

A
  1. Saves time repeatedly making decisions about what to record.
  2. Ensures nothing important is left out.
  3. Assists communication between developers
  4. Allows projects to be compared and required reused
141
Q

Benefits of prototyping [4]

A
  1. Helps with the design of the UI.
  2. Gets users involved, helping to capture and refine requirements.
  3. Minimise misunderstandings between developers and users
  4. Early detection of problems
142
Q

Situations not suited to agile development [5]

A

Heavily regulated environment
Large software development with distributed teams
Requirements are well-defined and unlikely to change
Customer is distant

143
Q

Situations suited to agile development [4]

A

Requirements are constantly changing
Developers and users can communicate regularly
The team is small enough that everyone can participate in a meeting
The developers like being empowered

144
Q

Write the signature for operation addQtyOfProductToOrder, which takes arguments of type Order, Integer and Product and is sent to the system class Store

A

context Store:addQtyOfProductToOrder(order: Order, quantity: Integer, product Product) : String

145
Q

Requirements must be _____ [6]

A
  1. Necessary and traceability
  2. Clear and realistic
  3. Complete
  4. Consistent
  5. Verifiable and validated
  6. Independent of design