Transcript Document

Models
• Modelling can help us to understand the
requirements thoroughly
• Ambiguous behaviour is revealed by holes
in the models
• Inconsistencies in requirements are revealed
by multiple, conflicting outputs to the same
input
1
Requirements Modelling
• Consists of:
– Decomposition
• the process by which a problem is broken down into parts
– Abstraction
• a description of the problem at some level of generalisation
that allows us to concentrate on the key aspects of the problem
without getting involved in the difficulties of the details.
– Separation of concerns
• the process of breaking a program into distinct features that
overlap, as little as possible, in functionality
2
Purposes of Decomposition
• Requirements specification is decomposed
along separate concerns to simplify the
resulting model and make it easier to read
and to understand
• In contrast , decomposition of a design
improve the system’s quality attributes
(modularity, maintainability, performance,
time to delivery, etc.)
3
Unified Modelling Language
• UML is a collection of notations used to document
software specifications and designs
• Represents a standard notation for modelling,
documenting, and communicating decisions
• Modelling
– helps us to understand requirements
– reveal inconsistencies in requirements (conflicting
outputs to same input)
4
Notations - ERD
• Entity-Relationship Diagrams
– Represents conceptual model and decomposes by entity
– Popular for describing database schema
– Mostly static, structural view and says nothing about
how entities are to behave
• Three core constructs, which are combined to
specify a problem’s elements and interrelationships:
– Entities (collection of real-world objects)
– Attributes (annotation that describes data or properties
associated with the entity)
– Relations
5
Notations – UML class diagram
• ER diagram in which
– entities are called actors
– Class is a collection of similarly typed entities
– Class has a name, set of attributes and operations
• Primarily for design notation but is used for
conceptual modelling, in which classes represent
real-world entities in the problem
• e.g. Conceptual model – Customer class which
corresponds to CustomerRecord class in program
class in implementation
6
Notations – Event Traces
• Describes system’s behavioural requirements
decomposed by scenario
– Not used to provide a complete description of required
behaviour as number of scenarios can become unwieldy
• Graphical depiction of a sequence of events that
are exchanged between real-world entities
– Vertical line represents timeline for an entity, whose
name appears on top of the line
– Horizontal line represents and event or interaction
between two entities bounding the line, i.e. a message
passed
– Time progresses from top to bottom, i.e. an upper event
happens before a lower event
• Each graph represents a single trace, i.e. only one
of the several possible behaviours
7
Notations – State Machines
• Used to represent a collection of event traces in a
single model decomposed by control state
– Used for specifying dynamic behaviour and for
describing how behaviour should change in response to
the history of events that have already occurred
• Graphical depiction of all dialog between the
system and its environment
– Each node (state) represents a stable set of conditions
that exist between event occurrences
– Each edge (transition) represents a change in behaviour
or condition due to the occurrence of an event
• Labelled with a triggering event and possibly an output event
generated when transition occurs
8
Notations – UML Statechart
Diagrams
• Depicts dynamic behaviour of objects in a UML
class
– Shows how class instances should change state and
how their attributes should change value as the objects
interact with each other
• UML model is a collection of concurrently
executing statecharts – one per instantiated object
– that communicate with each other via message
passing
• Each class in a UML class diagram has an
associated statechart diagram that specifies the
dynamic behaviour of objects of that class
9
Notations – Data-Flow Diagrams
• Promotes decomposition by functionality
– Models functionality and the flow of data from one
function to another
• Representations:
– Bubble  process or function that transforms data
– Arrow  data flow, into bubble represents an input and
out of bubble represents an output
– Data store is a formal repository or database of
information used to store data that persist beyond their
use in a single computation
– Actors (data sources or sinks) are entities that provide
input data or receive the output results
10
Notations – UML Use-case
Diagrams
• Similar to top-level data-flow diagram that depicts
observable, user-instantiated functionality in terms
of interactions between the system and its
environment.
• Components:
– Large box represents system boundary
– Stick figures outside box portray actors (humans and
systems)
– Each oval inside box is a use case that represents some
major required functionality and its variants
– Line between actor and use case indicates that actor
11
participates in the use case
Notations – UML Use-case
Diagrams
• Use cases are not meant to model all the
tasks in the system but used to specify user
views of essential system behaviour
• Model only system functionality that can be
initiated by some actor in the environment
12
Formal Methods/Approaches
• Mathematically based specification and
design techniques
• Encouraged by software developers who
build safety-critical systems
13
Advantages of Formal Methods
• Mathematical models are more precise and less
ambiguous than other models
• Mathematical models lend themselves to more
systematic and sophisticated analysis and
verification
• Many formal specifications can be checked
automatically for consistency, completeness, nondeterminism, reachable states, type correctness
14
Functions and Relations
• Some formal paradigms model requirements/
software behaviour as a collection of mathematical
functions or relations
• When function and relations are composed
together, they map the system inputs to system
outputs
• Functions
– Specify state of a system’s execution
– Specify outputs
• Relations
– Used instead of a function whenever an input value
maps to more than one output value
15
Function
• Systematic and straightforward test for
consistency and completeness
– Because it maps each input to a single output,
by definition it is consistent
– If it specifies an output for every distinct input,
total function, and is by definition complete
16
Logic
• Is a descriptive notation, which better
expresses global properties and constraints
– Descriptive notation describes a problem or
proposed solution in terms of its properties or
its invariant behaviour
• Consists of:
– a language for expressing properties
– a set of inference rules for deriving new,
consequent properties from the stated properties
17
Logic
• Used to express a property of a software
problem/system
– This property is an assertion about the problem
or system that should be true
– As such, a property specification represents
only those values of the property’s variables for
which the property’s expression evaluates true
18
First-order logic
•
•
•
•
•
•
Typed variables
Constants
Function
Predicates < and >
Equality
Logical connectives  (and),  (or), ¬ (not),
(implies), (logical equivalence)
• Quantifiers   (there exists) and  (for all)
19
Temporal logic
• Introduces additional logic connectives for
constraining how variables can change value over
time
– More precisely over multiple points in an execution
• The following (linear-time) connectives constrain
future variable values, over a single execution
trace:
–  f  f is true now and throughout the rest of the
execution
– f  f is true now or at some future point of the
execution
– f  f is true in the next point of the execution
– f W g  f is true until a point where g is true, but g may
never be true
20
• Properties may be often used to augment a
model-based specification either to:
– Impose constraints on model’s allowable
behaviour
• Property specifies behaviour not expressed in model
and the property
– Simply express redundant but non-obvious
global properties
• Property does not alter specified behaviour but may
aid in understanding the model by explicating
otherwise implicit behaviour
• Also aids in requirements verification, by providing
expected properties of the model for the reviewer to
check
21
Algebraic specifications
• Used to specify the behaviour of operations by
specifying the interactions between pairs of
operations rather than modelling individual
operations
– Multi-operational view – viewing system in terms of
what happens when combinations of operations are
performed
– Execution trace – a sequence of operations that have
been performed since the start of execution
22
Algebraic specification axioms
• Specify the effects of applying pair
operations on an arbitrary sequence of
operations that has already been executed
23
Disadvantage of Algebraic
specification
• For a collection of operations, it can be
tricky to construct a concise set of axioms
that is complete and consistent, and correct
24
Prototyping Requirements
• One way to elicit details
• It solicits feedback from potential users about
what aspects they would like to see improved
– which features are not so useful, or what functionality
is missing
• help determine whether customer’s problem has a
feasible solution
• Assist in exploring options for optimising quality
requirements
25
Rapid prototyping
• Involves building software to answer
questions about requirements
– Partial solution that is built to help us
understand the requirements or evaluate design
alternatives
– Different from prototyping, in which prototype
is a complete solution
• Whose purpose is to test and design product before
automating / optimising manufacturing step for mass
production
26
Types of Rapid Prototyping
Throwaway
• Developed to learn more
about a problem or a
proposed solution, and is
never intended to be part
of delivered software
• Allows “quick-and-dirty”
software to be built to be
written, i.e. poorly
constructed, inefficient,
with no error checking
Evolutionary
• Developed not only to
help us answer questions
but also to be incorporated
into the final product
• As such, more careful
development is
undertaken, because this
software has to eventually
exhibit quality
requirements (e.g.
response rate, modularity)
of the final product
– These qualities cannot be
retrofitted
27
Validation and Verification
• Requirements validation
– Checks that our requirements definition
accurately reflects all the stakeholder’s needs
• Requirements verification
– Check that one document or artefact conforms
to another
– Verifies that:
• Code conforms to design
• Design conforms to requirements specifications
• Requirements specification conforms to
requirements definition
28
Requirements Validation
•
Uses the following characteristics as the criteria
for validating requirements:
–
–
–
–
–
–
–
Correctness
Consistency
Unambiguity
Completeness
Relevance
Testability
Traceability
29
Requirements Validation Techniques
• Checklist
– Common errors can be recorded in a checklist, which
reviewers can use to guide their search for errors
• Reading
– Reading document and report errors
• Walkthrough
– One of the document’s authors presents the
requirements to the rest of the stakeholders, and asks
for feedback
• Formal Inspection
– Reviewers take on specific roles and follow prescribed
rules (when to meet or take breaks, when to schedule
follow-up inspection)
30
Requirements Validation Techniques
• Review
– Representative of developer’s staff and customer’s staff
examine the requirements document individually
– Then they meet to discuss identified problems
– Customer’s representatives may include those who will:
•
•
•
•
be operating the system
prepare the system’s inputs
use the system’s outputs
manager of these employees who attend
– Developer’s representatives include:
• design team
• test team
• process team
31
Requirements Verification
• Checking our requirements-specification
document correspond to our requirementsdefinition document
– Ensures a system ca be implemented that
• meets the specification
• satisfies customer’s requirements
• Most often, it is a check of traceability
32
Requirements Verification
• For critical systems, we may want to demonstrate
that the specification fulfils the requirements
– prove that the specification realises every function,
event, activity and constraint in the requirements
• To do this we need to make assumptions about
how the environment behaves
– Assumptions about what inputs the system will receive
– Assumptions about how the environment will react to
outputs
• We rely on our environment to help us satisfy the
customer’s requirements
– If our assumptions about how the environment behave
is wrong, then our system may not work as the
customer expects
33