1c System Specification

7/29/2019 1c System Specification

1/43


2/43

Agenda Software Application

CASE

CASE Tools System Specification


3/43

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 produceformatted reports.

Software that controls an automated machine

3


4/43

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

categories for software applications.

The following are the classification for software.

1. System Software

2. Embedded Software

3. Real-time Software

4. Business Software

5. Personal Computer Software

6. Engineering And Scientific Software

7. Artificial Intelligence Software


5/43

CASE CASE stands for Computer-Aided Software

Engineering.

CASE Technology provides software process.

CASE improve the software quality and producitvity.


6/43

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 otherteammembers.


7/43

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


8/43

Functional tool classificationTool type Examples

Planning tools PERT tools, estimation tools, spreadsheets

Editing tools Text editors, diagram editors, word processors

Change management tools Requirements traceability tools, change control systems

Configuration management tools Version management systems, system building tools

Prototyping tools Very high-level languages, user int erface generat ors

Method-support tools Design editors, data dictionaries, code generators

Language-processing tools Compilers, interpreters

Program analysis tools Cross reference generators, static analysers, dynamic analysers

Testing tools Test data generators, file comparators

Debugging tools Interactive debugging systems

Docum entation tools Page layout programs, image edit ors

Re-engineering tools Cross-reference systems, program re-structuring systems


9/43

Activity-based tool classification

Sp ecificatio n Design Implemen tatio n Verificat ion

and

Validat ion

Re-eng ineering t ools

Testing too ls

Debugging tools

Program analysis to ols

Language-processing

tools

Method suppor t to ols

Prototyping tool s

Configuration

management tools

Change man agement tools

Document ation too ls

Editing tool s

Planning t ools


10/43

CASE integration

Tools

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

Workbenches

Support a process phase such as specification or design,Normally include a number of integrated tools.

Environments

Support all or a substantial part of an entire softwareprocess. Normally include several integratedworkbenches.


11/43

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 maybe used to develop an implementation

Different type of Specification

1. Formal Specification2. Program Specification

3. Functional Specification

4. Document Specification


12/43

1. Risk-driven specification

2. Safety specification

3. Security specification4. Software reliability specification


13/43

Risk-driven specification

Critical systems specification should be risk-driven.

This approach has been widely used in safety andsecurity-critical systems.

The aim of the specification process should be tounderstand the risks (safety, security, etc.) faced bythe system and to define requirements that reducethese risks.


14/43

Stages of risk-based analysis

Risk identification Identify potential risks that may arise.

Risk analysis and classification

Assess the seriousness of each risk. Risk decomposition

Decompose risks to discover their potential rootcauses.

Risk reduction assessment Define how each risk must be taken into eliminated

or reduced when the system is designed.


15/43

Risk-driven specification


16/43

Risk identification

Identify the risks faced by the critical system.

In safety-critical systems, the risks are thehazards that can lead to accidents.

In security-critical systems, the risks are thepotential attacks on the system.

In risk identification, you should identify risk

classes and position risks in these classes Service failure

Electrical risks


17/43

Insulin pump risks Insulin overdose (service failure). Insulin under dose (service failure). Power failure due to exhausted battery (electrical).

Electrical interference with other medicalequipment (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).


18/43

Risk analysis and classification

The process is concerned with understanding thelikelihood that a risk will arise and the potentialconsequences if an accident or incident should occur.

Risks may be categorized as: Intolerable.

As low as reasonably practical (ALARP).

Acceptable.


19/43

Levels of risk

Unaccepta ble r egion

Ris k cannot b e toler ated

Ris k to lerated onl y if

risk reduction i s impr act ical

or g ross ly e xpensive

Acceptable

region

Negl igible ris k

ALARPregion


20/43

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, veryhigh, etc.


21/43

Risk assessment - insulin pump

Identified hazard Hazard

probability

Hazard

severity

Estimated

risk

Acceptability

1. Insulin overdose Medium High High Intolerable

2. Insulin underdose Medium Low Low Acceptable

3. Power failure High Low Low Acceptable

4. Machine incorrectly fitted High High High Intolerable

5. Machine breaks in patient Low High Medium ALARP

6. Machine causes infection Medium Medium Medium ALARP7. Electrical interference Low High Medium ALARP

8. Allergic reaction Low Low Low Acceptable


22/43

Risk decomposition

Concerned with discovering the root causes of risksin a particular system.

Techniques have been mostly derived from safety-

critical systems and can be

Inductive, bottom-up techniques.

Deductive, top-down techniques.


23/43

Risk reduction assessment

The aim of this process is to identify dependabilityrequirements that specify how the risks should bemanaged and ensure that accidents/incidents do notarise.

Risk reduction strategies

Risk avoidance;

Risk detection and removal;

Damage limitation.

a ety requ rements nsu n


24/43

a ety requ rements - nsu npump

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.


25/43

Safety specification

The safety requirements of a system should beseparately specified.

These requirements should be based on an analysisof the possible hazards and risks as previously

discussed. Safety requirements usually apply to the system as a

whole rather than to individual sub-systems.


26/43

Safety requirements

Functional safety requirements

These define the safety functions of the protectionsystem i.e. the define how the system should provideprotection.

Safety integrity requirements

These define the reliability and availability of theprotection system. They are based on expected usageand are classified using a safety integrity level (SIL)from 1 to 4.


27/43

Security specification

Has some similarities to safety specification

Differences

No well-defined notion of a security life cycle forsecurity management; No standards;

Generic threats rather than system specific hazards

Mature security technology (encryption, etc.).However, there are problems in transferring this intogeneral use


28/43

System reliability specification

Hardware reliability Software reliability

Operator reliability


29/43

Rate of fault occurrence (ROCOF)

Reflects the rate of occurrence of failure in thesystem.

ROCOF of 0.002 means 2 failures are likely ineach 1000 operational time units e.g. 2 failuresper 1000 hours of operation.

Relevant for operating systems, transactionprocessing systems where the system has to

process a large number of similar requests thatare relatively frequent Credit card processing system, airline booking

system.


30/43

1. Formal specification in the software process

2. Sub-system interface specification


31/43

Formal methods

Formal specification is part of a more generalcollection of techniques that are known asformal methods.

These are all based on mathematicalrepresentation and analysis of software.

Specification in the software


32/43


process

Specification and design are intermingled.

Architectural design is essential to structure aspecification and the specification process.

Formal specifications are expressed in amathematical notation with precisely definedvocabulary, syntax and semantics.



33/43


process


34/43

Use of formal specification

Formal specification involves investing more effort inthe early phases of software development.

This reduces requirements errors as it forces adetailed analysis of the requirements.

Incompleteness and inconsistencies can bediscovered and resolved.

Hence, savings as made as the amount of rework dueto requirements problems is reduced.


35/43

Cost profile

The use of formal specification means that the costprofile of a project changes

There are greater up front costs as more time andeffort are spent developing the specification

However, implementation and validation costsshould be reduced as the specification processreduces errors and ambiguities in the requirements.


36/43

Development costs with formal specification


37/43

Specification techniques

Algebraic specification

The system is specified in terms of its operations andtheir relationships.

Model-based specification The system is specified in terms of a state model that

is constructed using mathematical constructs suchas sets and sequences.


38/43

Interface specification

Large systems are decomposed into subsystemswith well-defined interfaces between thesesubsystems.

Specification of subsystem interfaces allowsindependent development of the differentsubsystems.

Interfaces may be defined as abstract data typesor object classes.


39/43

Sub-system interfaces


40/43

Specification components Introduction

Defines the sort (the type name) and declares otherspecifications 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.


41/43

Behavioural specification Model-based specification exposes the system state

and defines the operations in terms of changes to thatstate.

The Z notation is a mature technique for model-basedspecification. It combines formal and informaldescription and uses graphical highlighting whenpresenting specifications.


42/43

The structure of a Z schema


43/43

Thank youAnd

Question

Date post:	04-Apr-2018
Category:	Documents
Upload:	pnarona
View:	218 times
Download:	0 times

1c System Specification

Documents