Topic 5Summer 2003 1 ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter,...
-
Upload
jared-sparks -
Category
Documents
-
view
215 -
download
0
Transcript of Topic 5Summer 2003 1 ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter,...
Topic 5 Summer 2003 1
ICS 52: Introduction to Software Engineering
Lecture Notes for Summer Quarter, 2003
Michele Rousseau
Topic 5Partially based on lecture notes written by Sommerville, Richard N. Taylor, André van der Hoek, Dan Frost and Doris Tonne. Duplication of course material for any commercial purpose without the written permission of the lecturers is prohibited
Topic 5 Summer 2003 2
Today’s Lecture
Problems in RE Formal Methods
Topic 5 Summer 2003 3
Some Problems with RE Social and organisational factors
– Can dominate the system reqs– Not 1 viewpoint, but many– No systematic way to tackle these factors
Example– Consider a system which allows senior
management to access information without going through middle managers
• Managerial responsibilities. Managers may have no uninterrupted time where they can learn to use the system
• Organisational resistance. Middle managers who will be made redundant may deliberately provide misleading or incomplete information so that the system will fail
Ethnographic studies can help
Topic 5 Summer 2003 4
Domain Requirements
Derived from the application domain and describe system characterisics and features that reflect the domain
Example :Library System– There shall be a standard user interface to all
databases which shall be based on the Z39.50 standard.
– Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the user’s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer.
Topic 5 Summer 2003 5
Domain requirements problems
Understandability– Requirements are expressed in the
language of the application domain– This is often not understood by software
engineers developing the system Implicitness
– Domain specialists understand the area so well that they do not think of making the domain requirements explicit
Topic 5 Summer 2003 6
Requirements change management
Should apply to all proposed changes to the requirements
Principal stages– Problem analysis. Discuss requirements problem
and propose change– Change analysis and costing. Assess effects of
change on other requirements– Change implementation. Modify requirements
document and other documents to reflect change
Topic 5 Summer 2003 7
Enduring and volatile requirements
Enduring requirements. Stable requirements derived from the core activity of the customer organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models
Volatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy
Topic 5 Summer 2003 8
Problems with NL Specification
Ambiguity– The readers and writers of the requirement must interpret
the same words in the same way. NL is naturally ambiguous so this is very difficult
– Lack of rigor Over-flexibility
– The same thing may be said in a number of different ways in the specification
Lack of modularisation– NL structures are inadequate to structure system
requirements Difficult to Prove Correctness
Topic 5 Summer 2003 9
How Can We Ensure Completeness?
Traceability is concerned with the relationships between requirements, their sources and the system design
Source traceability– Links from requirements to stakeholders
Requirements traceability– Links between dependent requirements
Design traceability– Links from the requirements to the design
Topic 5 Summer 2003 10
Example: Traceability Matrix
U=> Uses , R=>Relates
Topic 5 Summer 2003 11
Alternatives to NL specificationNotation DescriptionStructurednaturallanguage
This approach depends on defining standard forms ortemplates to express the requirements specification.
Designdescriptionlanguages
This approach uses a language like a programming languagebut with more abstract features to specify the requirementsby defining an operational model of the system.
Graphicalnotations
A graphical language, supplemented by text annotations isused to define the functional requirements for the system.An early example of such a graphical language was SADT(Ross, 1977; Schoman and Ross, 1977). More recently, use-case descriptions (Jacobsen, Christerson et al., 1993) havebeen used. I discuss these in the following chapter.
Mathematicalspecifications
These are notations based on mathematical concepts suchas finite-state machines or sets. These unambiguousspecifications reduce the arguments between customer andcontractor about system functionality. However, mostcustomers don’t understand formal specifications and arereluctant to accept it as a system contract. I discuss formalspecification in Chapter 9.
Topic 5 Summer 2003 12
Structured language specifications
A limited form of natural language may be used to express requirements
Removes Ambiguity and Flexibility Imposes Uniformity Often bast supported using a forms-
based approach
Topic 5 Summer 2003 13
Form-based specifications
Definition of the function or entity Description of inputs and where they
come from Description of outputs and where they go
to Indication of other entities required Pre and post conditions (if appropriate) The side effects (if any)
Topic 5 Summer 2003 14
Form-based node specificationECLIPSE/Workstation/Tools/DE/FS/3.5.1
Function Add node
Description Adds a node to an existing design. The user selects the type of node, and its position.When added to the design, the node becomes the current selection. The user chooses the node position bymoving the cursor to the area where the node is added.
Inputs Node type, Node position, Design identifier.
Source Node type and Node position are input by the user, Design identifier from the database.
Outputs Design identifier.
Destination The design database. The design is committed to the database on completion of theoperation.
Requires Design graph rooted at input design identifier.
Pre-condition The design is open and displayed on the user's screen.
Post-condition The design is unchanged apart from the addition of a node of the specified typeat the given position.
Side-effects None
Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1
Topic 5 Summer 2003 15
PDL-based requirements definition Requirements may be defined operationally using a language like a
programming language but with more flexibility of expression Most appropriate in two situations
– Where an operation is specified as a sequence of actions and the order is important
– When hardware and software interfaces have to be specified Disadvantages are
– The PDL may not be sufficiently expressive to define domain concepts– The specification will be taken as a design rather than a specification
Topic 5 Summer 2003 16
Part of an ATM specification
class ATM {// declarations herepublic static void main (String args[]) throws InvalidCard {
try {thisCard.read () ; // may throw InvalidCard exceptionpin = KeyPad.readPin () ; attempts = 1 ;while ( !thisCard.pin.equals (pin) & attempts < 4 )
{ pin = KeyPad.readPin () ; attempts = attempts + 1 ;}if (!thisCard.pin.equals (pin))
throw new InvalidCard ("Bad PIN");thisBalance = thisCard.getBalance () ;do { Screen.prompt (" Please select a service ") ;
service = Screen.touchKey () ;switch (service) {
case Services.withdrawalWithReceipt:receiptRequired = true ;
Topic 5 Summer 2003 17
PDL disadvantages
PDL may not be sufficiently expressive to express the system functionality in an understandable way
Notation is only understandable to people with programming language knowledge
The requirement may be taken as a design specification rather than a model to help understand the system
Topic 5 Summer 2003 18
Formal Specification
Techniques for the unambiguous specification of software
Topic 5 Summer 2003 19
Formal methods
Formal specification is part of a more general collection of techniques that are known as ‘formal methods’
Formal Method (FM) =– specification language + formal reasoning
Body of techniques supported by– precise mathematics– powerful analysis tools
Topic 5 Summer 2003 20
Formal Specifications: what and why?
Use of formalisms– e.g., logic, discrete mathematics, formal languages
To describe systems– e.g., system models, constraints, requirements, designs
For broad range of effects– e.g., highly reliable, secure, safe systems and more effective
production With varying levels of use
– guidance: structuring what to say– documentation: unambiguous communication– rigor: formal specification and proofs– mechanisms: proof assistance, testing
Topic 5 Summer 2003 21
Formal Specification inSoftware Development
Formal specifications ground the software development process in the well-defined basis of computer science
Orientation goes from customer to developer Formal specification expressed in language whose
syntax and semantics are formally defined– hierarchical decomposition– mathematical foundation– graphical presentation– accompanied by informal description
Topic 5 Summer 2003 22
Goals and Objectives Requirements Specification
– clarify customer's requirements
– reveal ambiguity, inconsistency, incompleteness System/Software Design
– module identification and decomposition from structural specifications of component relations and behavioral specification of components
– refinement demonstrating that next level of abstraction satisfies higher level
Verification
– proving an implementation satisfies its specification Validation
– testing and debugging Documentation
– communication between specifier, implementor, customer, clients
Topic 5 Summer 2003 23
Benefits of UsingFormal Specifications and Methods
higher quality software verifiability of implementation insight and understanding minimized maintenance and cost automated assistance formal analysis guidance for testing transformation technology reduced liability and risks promotes reusability
Topic 5 Summer 2003 24
Formal Methods are not yet widely used
Reasons– emerging technology with unclear payoff– little experience– lack of automated support– not especially user friendly– too many in-place techniques and tools
Excuses
– high learning curve– mathematical sophistication required– techniques not widely applicable– ignorance of advances
Topic 5 Summer 2003 25
Desirable Properties ofFormal Specifications Consistency
– an implementation exists that satisfies a specification Complete (incrementally)
– all required aspects are specified Unambiguous
– all implementations that satisfy the specification are satisfactory (tradeoffs with completeness)
Inference– the ability to prove properties about implementations that
satisfy a specification– the ability to prove that an implementation satisfies a
specification
Topic 5 Summer 2003 26
Types of Formal Specifications
Behavioral specifications describe constraints on behavior of implementation – e.g.,– functionality– safety– security– performance
Structural specifications describe constraints on internal composition of implementation– module interconnection– uses and is-composed-of– dependence relations
Topic 5 Summer 2003 27
Characteristics of Specification & Support
Model-oriented specifications– specify system behavior by constructing a model in terms of well-defined
mathematical constructs Property-oriented specifications
– specify system behavior in terms of properties that must be satisfied Visual specifications
– specify system behavior and structure by graphical depictions Executable specifications
– specify system behavior completely enough that specifications can run on a computer
Tool support– syntactic checking– model checking– proof checking
Topic 5 Summer 2003 28
Basic Types of Behavioral Specification
Abstract Model Specifications– defines operations in terms of well-defined mathematical
model
Algebraic Specifications– defines a system using a heterogeneous algebra
State Transition Specifications– defines operations in terms of states and transitions
Axiomatic Specifications– defines operations by logical assertions
Topic 5 Summer 2003 29
Formal Specification Languages:Clock Example
+ Initially, the time is midnight, the bell is off, and the alarm is disabled.
+ Whenever the current time is the same as the alarm time and the alarm is enabled, the bell starts ringing.This is the only condition under which the bell begins to ring.
+ The alarm time can be set at any time.+ Only when the alarm is enabled can it be disabled.
+ If the alarm is disabled while the bell is ringing, the bell stops ringing.+ Resetting the clock and enabling or disabling the
alarm are considered to be done instantaneously.
Topic 5 Summer 2003 30
Abstract Model Specifications Explicitly describes behavior in terms of a model using well-defined
types (sets, sequences, relations, functions) and defines behavior by showing effects on model– State is explicit in the model– Objects can be built hierarchically
Specification includes– type definition: syntax of object being specified– model: underlying structure– invariants: properties of modeled object– pre/post conditions: semantics of operations
Pros and Cons– may suggest an implementation– widely applicable because of modeling orientation
Various notations: VDM, Z, RAISE
Topic 5 Summer 2003 31
Abstract Model Specifications:Process using Z
Specification using Z abstract model specifications– 1. Given sets, data types, and constants– 2. State definitions and invariants– 3. Initial state– 4. Operations
Topic 5 Summer 2003 32
Abstract Model Specifications:the Z Notation
specification name [generic parameters]
declaration
predicate
a Z specification is a collection of schemas a schema introduces some sets, data types, constants, and invariant
properties the schema declaration defines each variable's name and type
(syntax) the predicate defines the relationships between the entities that must
always hold (semantics)
Topic 5 Summer 2003 33
Abstract Model Specifications:Z ClockBellStatus: {quiet, ringing}, AlarmStatus: {disabled, enabled}
Clocktime, alarm_time: Nbell: BellStatusalarm: AlarmStatus
InitClockClock
(time = midnight) (bell = quiet) (alarm = disabled)
Tick
Clock
(time = succ(time)) (alarm_time = time) (alarm = enabled) => (bell = ringing)(~((alarm_time = time) (alarm = enabled)) => (bell = bell)(alarm = alarm) (alarm_time = alarm_time)
Topic 5 Summer 2003 34
SetAlarmTimeClocknew_time
alarm_timenew_time?)((alarm_time = time) (alarm = enabled) => (bell = ringing) (~((alarm_time = time) (alarm = enabled)) => (bell = bell)(time = time) (alarm = alarm)
EnableAlarm Clock
(alarm = disabled) => (alarm = enabled) ( (alarm_time= time) => (bell = ringing) (~(alarm_time = time)) => (bell= bell) ) (time= time) (alarm_time= alarm_time)
DisableAlarm Clock
(alarm = enabled) => (alarm = disabled) (bell = quiet) (time = time) (alarm= alarm) (alarm_time= alarm_time)
Topic 5 Summer 2003 35
State Transition Specifications Explicitly describes system behavior by a set of states and defines
operations as transitions between states or observations on state Specification includes
– states: possible values– transitions: semantics by state transformations and observations
Pros and Cons– free of representational details (except augmentations)– state explosion is common– extensions to minimize states and modularize– particularly applicable to control systems, languages, hardware
Graphical as well as textual notations: StateCharts, ASLAN, Paisley,InaJo, Special
Topic 5 Summer 2003 36
State Transition Specifications:State Charts Clock
off
ringing
CLOCK
tick alarm
up
quiet
on
[alarm_time = time]
enabled disabled
time':= succ(time)
time' := midnight
gettime
disabled
Topic 5 Summer 2003 37
Algebraic Specification Objects specified as algebraic sorts in terms of axiomatic relations
between associated operations– State is concealed in objects– Objects can be built hierarchically
Specification includes– sets and functions: syntax and legal constructions– relations between functions
Pros and Cons– only pure functions described (no side effects)– supports extensibility of data abstractions– often hard to comprehend and construct
Various notations: OBJ, Larch, Clear, Anna
Topic 5 Summer 2003 38
Algebraic Specifications: Process
Specification using heterogeneous algebras– 1. establish the sorts (sets) (objects and
attributes)– 2. establish the necessary operations along
with their domains and ranges• constructor operations
• access operations
– 3. establish the axiomatic relations