What is a software component?
A software component is a unit of software structured according to the following principles:
- A component encapsulates data and operations
- A component is fully documented and thoroughly tested
- A component’s specification clearly separates the component’s interface from its implementation
- A component’s specification may include non-functional characteristics
- A component is known to client components only through its interface
(b3, p58)
What is the difference between a provided interface and a required interface?
A provided interface is a description of a set of operations a component makes available to other components.
A required interface is a description of a set of operations a component needs from other components.
(b3, p59)
Draw a graphical stereotype and a textual stereotype.
(b3, p60)
How are interfaces represented in UML?
(b3, p60)
What is a service?
A service is an abstract description of some unit of business functionality, usually described in terms that are meaningful from both a business and a technical perspective.
(b3, p66)
What are the 4 main similarities between services and components?
- Well defined interfaces
- Loosely coupled
- Can be composed
- Reusable
(b3, p66-67)
What are the 6 main differences between services and components?
- Components tend to depend on proprietary technologies, whereas services use standard communication protocols
- Services are discoverable - they can be found by accessing a repository
- Components run on computers controlled by the organisation using them, whereas a service resides on a provider server
- Services should be autonomous and independent of other services, so do not have a ‘requires’ interface
- Services can be stateless, meaning they do not retain any memory of previous requests
- Clients can often use a service without needing to know its physical location - a service can be moved to a different computer without clients being affected
(b3, p67)
S SEAR R
What are the 6 components of a quality attribute scenario?
- Source
- Stimulus
- Artefact
- Environment
- Response
- Response measure
(b3, p71-72)
What are the types of value for performance scenario parts?
(I.e. types of value for source, stimulus, artefact, environment, response, response measure)
Source:
- internal
- external
Stimulus:
- periodic events
- sporadic events
- bursty events
- stochastic events
Artefact:
- system
Environment:
- normal
- overload
Response:
- process stimuli
- change level of service
Response measure:
- latency
- deadline
- throughput
- jitter
- miss rate
- data loss
(b3, p72)
What are the 4 types of stimulus events in performance scenarios?
- Periodic - at regular intervals
- Sporadic - infrequent and isolated
- Bursty - sudden and unpredictable clusters overlaying normally low background activity
- Stochastic - occurring randomly but according to a well-defined probability distribution (e.g. heads on a coin flip)
(b3, p72-73)
What are the 6 types of response measures in performance scenarios?
- Latency - time taken to process a stimulus
- Deadline -
- Throughput - number of events dealt with in a given time
- Jitter - amount of variation in latency
- Miss rate - proportion of events that are not responded to
- Data loss - how much data is lost because the system fails to record it
(b3, p73)
What are the types of value for usability scenario parts?
(I.e. types of value for source, stimulus, artefact, environment, response, response measure)
Source:
- end users
Stimulus:
- user wants to learn system features
- user wants to use system efficiently
- user wants to minimise impact of errors
- user wants to feel comfortable
Artefact:
- system
Environment:
- setting preferences
- using system
Response:
- supporting learning
- supporting efficient use
- minimising impact of errors
- allowing adaptation
- making user comfortable
Response measure:
- task time
- number of errors
- number of problems solved
- user satisfaction
- success rate
- time taken or data lost
(b3, p76)
What are the 3 design tactics for meeting performance requirements?
- Manage demand
- Manage system capacity
- Match resource to demand
(b3, p78-79)
What are the 4 design tactics for meeting flexibility requirements?
- Minimise coupling
- Maximise cohesion
- Keep modules small
- Bind as late as possible
(b3, p81-83)
