Agenda

Software Application
CASE CASE Tools System Specification

Software Application
Software may be applied in any situation.
Information content and determinacy are important

factors. Content refers to the meaning and form of incoming and outgoing information. For example, many business applications use highly structured input data (a database) and produce formatted reports. Software that controls an automated machine
3

Software Application(Cont..)
It is somewhat difficult to develop meaningful generic

categories for software applications. The following are the classification for software.
1.

2.
3. 4. 5. 6. 7.

System Software Embedded Software Real-time Software Business Software Personal Computer Software Engineering And Scientific Software Artificial Intelligence Software

CASE
CASE stands for Computer-Aided Software Engineering.
CASE Technology provides software process. CASE improve the software quality and producitvity.

The use of CASE are limited by two factors:

Design activity based on a creative thought. It has been hardness technology to provide support for design have not been successful.
Software Engineering is a team activity and they spend a lot of time interacting with other team members.

CASE Classification
It helps us to understand the types of CASE tools and their role in supporting software process activities.
CASE tool from 3 of these perspectives

A function perspective A process perspective An integration perspective

Functional tool classification

Tool type Planning tools Editing tools Change management tools Configuration management tools Prototyping tools Method-support tools Language-processing tools Program analysis tools T esting tools Debugging tools Documentation tools Re-engineering tools Examples PERT tools, estimation tools, spreadsheets T ext editors, diagram editors, word processors Requirements traceability tools, change control systems Version management systems, system building tools Very high-level languages, user interface generators Design editors, data dictionaries, code generators Compilers, interpreters Cross reference generators, static analysers, dynamic analysers T est data generators, file comparators Interactive debugging systems Page layout programs, image editors Cross-reference systems, program re-structuring systems

Activity-based tool classification

Re-en g ineering tools Testin g too ls Debu gg ing too ls Prog ram analy sis to ols Lang uage-p ro ces sing too ls Meth od s up po r t to ols Proto ty ping too ls Co nfiguration management to ols Ch an ge man ag emen t too ls Do cu men tatio n too ls Ed iting too ls Planning to ols

Sp ecif icatio n

Design

Implemen tatio n

V erification and V alidatio n

CASE integration

Tools

Support individual process tasks such as design consistency checking, text editing, etc.

Workbenches

Support a process phase such as specification or design, Normally include a number of integrated tools.
Support all or a substantial part of an entire software process. Normally include several integrated workbenches.

Environments

System Specification

A specification is an explicit set of requirements to be satisfied by a material, product, or service. In computer science, a formal specification is a mathematical description of software or hardware that may be used to develop an implementation

Different type of Specification 1. Formal Specification 2. Program Specification 3. Functional Specification 4. Document Specification

1.
2. 3.

4.

Risk-driven specification Safety specification Security specification Software reliability specification

Risk-driven specification

Critical systems specification should be risk-driven. This approach has been widely used in safety and security-critical systems. The aim of the specification process should be to understand the risks (safety, security, etc.) faced by the system and to define requirements that reduce these risks.

Stages of risk-based analysis

Risk identification

Identify potential risks that may arise. Assess the seriousness of each risk. Decompose risks to discover their potential root causes. Define how each risk must be taken into eliminated or reduced when the system is designed.

Risk analysis and classification

Risk decomposition Risk reduction assessment

Risk-driven specification

Risk identification
Identify the risks faced by the critical system. In safety-critical systems, the risks are the hazards that can lead to accidents.

In security-critical systems, the risks are the potential attacks on the system.
In risk identification, you should identify risk

classes and position risks in these classes

Service failure Electrical risks

Insulin pump risks

Insulin overdose (service failure). Insulin under dose (service failure). Power failure due to exhausted battery (electrical). Electrical interference with other medical

equipment (electrical). Poor sensor and actuator contact (physical). Parts of machine break off in body (physical). Infection caused by introduction of machine (biological). Allergic reaction to materials or insulin (biological).

Risk analysis and classification

The process is concerned with understanding the likelihood that a risk will arise and the potential consequences if an accident or incident should occur. Risks may be categorized as:

Intolerable. As low as reasonably practical (ALARP). Acceptable.

Levels of risk
Un accepta ble r egion Ris k cann ot b e t oler ated Ris k to lerated o nl y i f ris k reductio n i s impr actical or g ros s ly e xpensive

AL ARP region

Acceptab l e reg ion

Negligi ble ris k

Risk assessment

Estimate the risk probability and the risk severity. It is not normally possible to do this precisely so relative values are used such as unlikely, rare, very high, etc.

Risk assessment - insulin pump

Identified hazard 1. Insulin overdose 2. Insulin underdose 3. Power failure 4. Machine incorrectly fitted 5. Machine breaks in patient 6. Machine causes infection 7. Electrical interference 8. Allergic reaction Hazard probability Medium Medium High High Low Medium Low Low Hazard severity High Low Low High High Medium High Low Estimated risk High Low Low High Medium Medium Medium Low Acceptability Intolerable Acceptable Acceptable Intolerable ALARP ALARP ALARP Acceptable

Risk decomposition

Concerned with discovering the root causes of risks in a particular system. Techniques have been mostly derived from safetycritical systems and can be

Inductive, bottom-up techniques. Deductive, top-down techniques.

Risk reduction assessment

The aim of this process is to identify dependability requirements that specify how the risks should be managed and ensure that accidents/incidents do not arise. Risk reduction strategies

Risk avoidance; Risk detection and removal; Damage limitation.

Safety requirements - insulin pump

SR1: The system shall not deliver a single dose of insulin that is greater than a specified maximum dose for a system user. SR2: The system shall not deliver a daily cumulative dose of insulin that is greater than a specified maximum for a system user. SR3: The system shall include a hardware diagnostic facili ty that shall be executed at least 4 times per hour. SR4: The system shall include an exception handler for all of the exceptions that are identified in Table 3. SR5: The audible alarm shall be sounded when any hardware or software anomaly is discovered and a diagnostic message as defined in Table 4 should be displayed. SR6: In the event of an alarm in the system, insulin delivery shall be suspended until the user has reset the system and cleared the alarm.

Safety specification

The safety requirements of a system should be separately specified. These requirements should be based on an analysis of the possible hazards and risks as previously discussed. Safety requirements usually apply to the system as a whole rather than to individual sub-systems.

Safety requirements

Functional safety requirements

These define the safety functions of the protection system i.e. the define how the system should provide protection. These define the reliability and availability of the protection system. They are based on expected usage and are classified using a safety integrity level (SIL) from 1 to 4.

Safety integrity requirements

Security specification
Has some similarities to safety specification Differences

No well-defined notion of a security life cycle for security management; No standards; Generic threats rather than system specific hazards Mature security technology (encryption, etc.). However, there are problems in transferring this into general use

System reliability specification

Hardware reliability Software reliability Operator reliability

Rate of fault occurrence (ROCOF)

Reflects the rate of occurrence of failure in the system. ROCOF of 0.002 means 2 failures are likely in

each 1000 operational time units e.g. 2 failures per 1000 hours of operation. Relevant for operating systems, transaction processing systems where the system has to process a large number of similar requests that are relatively frequent

Credit card processing system, airline booking system.

1. 2.

Formal specification in the software process Sub-system interface specification

Formal methods
Formal specification is part of a more general collection of techniques that are known as formal methods. These are all based on mathematical representation and analysis of software.

Specification in the software process

Specification and design are intermingled. Architectural design is essential to structure a specification and the specification process. Formal specifications are expressed in a mathematical notation with precisely defined vocabulary, syntax and semantics.

Specification in the software process

Use of formal specification

Formal specification involves investing more effort in the early phases of software development. This reduces requirements errors as it forces a detailed analysis of the requirements. Incompleteness and inconsistencies can be discovered and resolved. Hence, savings as made as the amount of rework due to requirements problems is reduced.

Cost profile

The use of formal specification means that the cost profile of a project changes

There are greater up front costs as more time and effort are spent developing the specification However, implementation and validation costs should be reduced as the specification process reduces errors and ambiguities in the requirements.

Development costs with formal specification

Specification techniques

Algebraic specification

The system is specified in terms of its operations and their relationships. The system is specified in terms of a state model that is constructed using mathematical constructs such as sets and sequences.

Model-based specification

Interface specification
Large systems are decomposed into subsystems with well-defined interfaces between these subsystems. Specification of subsystem interfaces allows independent development of the different subsystems. Interfaces may be defined as abstract data types or object classes.

Sub-system interfaces

Specification components
Introduction
Defines the sort (the type name) and declares other

specifications that are used.

Description
Informally describes the operations on the type.

Signature
Defines the syntax of the operations in the interface and

their parameters.

Axioms
Defines the operation semantics by defining axioms

which characterise behaviour.

Behavioural specification
Model-based specification exposes the system state

and defines the operations in terms of changes to that state. The Z notation is a mature technique for model-based specification. It combines formal and informal description and uses graphical highlighting when presenting specifications.

The structure of a Z schema

Thank you And Question