Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

FORMAL METHODS

VIEWS: 197 PAGES: 49

									   FORMAL
   METHODS
ROSLINA BINTI MOHD SIDEK
        EXT 2104




                           1
Chapter 1 : Overview
   Introduction
       SE methods can be categorized on a
        informality spectrum that is loosely tied to the
        degree of mathematical.
       Applied during analysis and design
       Normally – informal.




                                                           2
Formal Methods(FM) and SE
   What is FM?
          FM allows a soft engineer to create a specification that
           is more complete, consistent and unambiguous than
           those produced using conventional methods.
          Set theory and logic notation are used to create a clear
           statement of facts(requirement)
          This mathematical specification can then be analyzed
           to improve or prove correctness and consistency.
          Because the specification is created using
           mathematics notation.




                                                                  3
   Why is it important?
         in safety-critical or mission-critical systems, failure can
          have a high price.
         Lives may be lost or severe economic consequences
          can arise when comp soft fails.
         In such situations it is essential that errors are
          uncovered before it is put into operation.
         FM reduce specification errors dramatically and as a
          consequences, serve as the basis for software that has
          very few errors once the customers begin using it.




                                                                        4
   What are the step?
         the notations and heuristics of sets and constructive
          specification – form the basis of formal methods.
         Formal methods defines the data invariant, states and
          operations for a system function by translating informal
          requirements or the problem into a more formal
          representation.
   What is the work product?
         a specification represented in a formal language such as
          OCL or Z is produced when formal methods are applied.




                                                                     5
   Why aren’t they used everywhere?

       Formal methods are controversial. Their advocates claim that
        they can revolutionize [software] development.

       Their detractors think that they are impossibly difficult.
        Meanwhile, for most people, formal methods are so unfamiliar
        that it is difficult to judge the competing claims.– Anthony Hall,
        1990.




                                                                             6
Why FMs were developed?

   Two main reasons:
       the interpretation of natural language
            Need for a specific legal language to deal with issues of law.
            Wording could be misconstrued and loopholes discovered.

       The manipulation of specifications.
            Natural language is large and complex and cannot easily be
             manipulated.
            FM allowing such things as automatic algebraic
             simplification and proof analysis.



                                                                          7
Natural language Specification
   The most obvious way of describing requirements
    is to use natural language – easily readable and
    widely understood.
   However, it tend to be verbose and can suffer
    from a variety of problems.
   The problems are:
          Ambiguity
          Incompleteness
          vagueness
          contradiction



                                                       8
   Ambiguity
      statements that can be interpreted in a number
       of ways. They usually do not appear ambiguous
       to the author.
      The operator identity consists of the operator
       name and password; the password consists of
       six digits. It should be displayed on the security
       VDU and deposited into the login file when an
       operator logs into the system.
      What does “it” refer to – the operator or the
       password?


                                                            9
   Incompleteness
        missing details such as a failure to specify what should
         occur in certain conditions. The system should maintain the
         hourly level of the reservoir from depth sensors in the
         reservoir. These values should be stored for the past six
         months.




                                                                   10
   Vagueness– often occurs because the specification
    document is bulky. Achieving a high level of
    precision consistently is an almost impossible task.
             The interface to the system used by the radar operators
              should be user-friendly.
             The above statement contains no useful information!




                                                                        11
   Contradiction– sets of statements that are in variance
    with each other. They are often written by different
    people and separated by many pages in the
    specification.
      They are therefore difficult to detect.




                                                         12
   Mixed levels of abstraction
        leads to difficulty in seeing the overall functional
         architecture of a system.
        For example, if the following statements were
         intermixed.
            The purpose of the system is to track the stock in a
             warehouse. When the loading clerk types in the
             withdraw command he or she will communicate the
             order number, the identity of the item to be removed,
             and the quantity removed. The system will respond with
             a confirmation that the removal is this leads to a lack of
             clarity.

                                                                      13
The advantages of FMs
   FMs offer distinct advantages over normal process of
    program development.
   The advantages are:
       Formal specification allow precise interpretation.
       Formal Methods allow system to be defined in abstract terms
       A formal methodology demands attention to issues of
        completeness and consistency
       The use of a formal methodology allows the progressive
        refinement of an abstract specification into a concrete
        specification using well-defined rules.
       Using formal description it is possible to detect deviations of a
        program from its original specification.




                                                                            14
Requirement of Formal System
   A formal methodology to be complete it must be
    able to fulfill the following requirement:
       Specification
            Possible to state what a program is meant to do in a formal
             precise way.

       Verification
            Given the specification and a program obtained, it should be
             possible to prove using formal mathematical methods that
             the program does what the specification states.



                                                                           15
The Application of FMs
   Petri Nets: C. A. Petri, 1962
   VDM:     The Vienna Development Method, IBM Vienna Laboratory,
              1970, ISO/IEC 13817, 1996
   Z:       The Z Notation, J. R. Abrial, I. Hayes, and C.A.R. Hoare,
              1970s; J.M. Spivey, 1989 (Oxford)
   SDL:     Specification and Description Language, CCITT (ITU), 1976
   CSP:     Communicating Sequential Processes, C.A.R. Hoare, 1985
   LOTOS: Language of Temporal Ordering Specifications,
               ISO/IEC8807, 1986 (Based on CCS)
   CCS:      Calculus of Communicating Systems, R. Milner, 1989
   RAISE: Rigorous Approach to Industrial Software Engineering,
               RAISE Group, 1992 (Based on VDM)
   B:        The B-Book: Assigning Programs to Meanings,
               J. R. Abrial, 1996 (Based on Z)
   UML:      The Unified Modeling Language, I. Rumbaugh, I. Jacobson,
               and G. Booch, 1998 (Partially based on SDL, SMC)
   RTPA: The Real-Time Process Algebra, Y. Wang, U of C, 2000
   Object-Z: Software Verification Research Centre, University of
                Queensland, 2000 (Based on Z)

                                                                         16
Cont…
   Classification of FMs are:
       Logic-Based FMs
       Algebra-Based FMs
       Diagram-Based FMs




                                 17
Cont…
   Logic-Based FMs
      Z: is a set of formal notations and rules for describing
        algebraic relations of software engineering
        processes.

             Since it uses schemata in system modeling, Z is also
              classified as model-based method.

             Related methods: Object-Z, and B

       VDM:        The Vienna Development Method

       RAISE: Rigorous Approach to Industrial Software
                Engineering


                                                                     18
Cont…
   Algebra-based FMs
       Algebra is a form of mathematics that simplifies difficult
        problems by using symbols to represent variables, calculus,
        and their relations and combinational rules.

       Process algebra is a set of formal notations and rules for
        describing algebraic relations of software engineering
        processes.

       Hoare: Communicating Sequential Processes (CSP)
       Milner: the Calculus of Communicating Systems (CCS)
       Wang: Real-time process algebra (RTPA)
       ISO/IEC8807: Language of Temporal Ordering
                      Specifications (LOTUS)

                                                                      19
Cont…
   Diagram-based FMs
       SDL: SDL/GR (SDL/TX)

       Petri Nets: Petri Nets is a formal and graphical
        appealing language which is appropriate for modeling
        systems with concurrency.

            Petri Nets has been under development since the
             beginning of the 60'ies, where Carl Adam Petri defined
             the language.

       UML: The Unified Modeling Language



                                                                      20
FMs : A Review on SE
   Introduction of SE
       What is software?
            A Software consists of …
               Computer programs &
               their associated documentations
            Software products may be…
               Generic - developed for a general market & to be sold to a
                range of different customers
               Bespoke (or custom) - developed for a particular customer
                or for a single customer according to their specification



                                                                        21
FMs : A Review on SE
   What is software engineering?
       Software engineering is an engineering
        discipline which is concerned with all aspects of
        software production
       Software engineers should adopt a systematic
        and organised approach to their work and use
        appropriate tools and techniques depending on
        the problem to be solved, the development
        constraints and the resources available



                                                            22
FMs : A Review on SE
   Software engineering is an engineering
    discipline which is concerned with all aspects of
    software production.
   Software products consist of developed programs
    and associated documentation.
   Essential product attributes are maintainability,
    dependability, efficiency and usability.



                                                    23
Cont…
   The software process consists of activities
    which are involved in developing software
    products.
   Basic activities are software specification,
    development, validation and evolution.
   Methods are organised ways of producing
    software. They include suggestions for the
    process to be followed, the notations to be
    used, rules governing the system descriptions
    which are produced and design guidelines.
                                                    24
Cont…
   CASE tools are software systems which are designed to
    support routine activities in the software process such as
    editing design diagrams, checking diagram consistency and
    keeping track of program tests which have been run.
   Software engineers have responsibilities to the engineering
    profession and society. They should not simply be concerned
    with technical issues.
   Professional societies publish codes of conduct which set
    out the standards of behaviour expected of their members.




                                                             25
FMs: A Review on SE
   What is a software process?
       It is a set of activities whose goal is the development or
        evolution of software
       Generic activities in all software processes are:
            Specification - what the system should do and its
             development constraints
            Development - production of the software system
            Validation - checking that the software is what the customer
             wants
            Evolution - changing the software in response to changing
             demands


                                                                            26
FMs : A Review on SE..sw process
   What is a software process model?
     A simplified representation of a software
      process, presented from a specific
      perspective
     Examples of process perspectives are

           Workflow perspective - sequence of activities
           Data-flow perspective - information flow
           Role/action perspective - who does what



                                                            27
FMs : A Review on SE..sw process
   Software process model?
     Generic process models

          Waterfall
          Evolutionary development
          Formal transformation
          Integration from reusable components




                                                  28
                   Waterfall model
Requirements
  definition


                 System and
               software design


                                 Implementation
                                 and unit testing


                                                    Integr ation and
                                                     system testing


                                                                       Operation and
                                                                       maintenance


                                                                                       29
      Evolutionary development
               Concurr ent
                activities

                                 Initial
              Specification
                                version


 Outline                      Intermediate
              Development
description                     versions


                                 Final
               Validation
                                version




                                             30
    Formal systems development


Requirements     Formal            Formal       Integration and
 definition    specification   transformation    system testing




                                                                  31
Spiral model of the software process

 Determine objectives
                                                                         Evaluate alternatives
   alternatives and                                                      identify, resolve risks
      constraints                                             Risk
                                                             analysis
                                                       Risk
                                                     analysis
                                               Risk
                                              analysis                                 Opera-
                                                                     Prototype 3       tional
                                                          Prototype 2                  protoype
                                             Risk
                               REVIEW          ysis Proto-
                                            anal
                                                    type 1
                        Requirements plan                       Simulations, models, benchmarks
                         Life-cycle plan    Concept of
                                            Operation        S/W
                                                         requirements    Product
                                                                         design      Detailed
                                            Requirement                              design
                           Development
                              plan           validation                         Code
                                               Design                    Unit test
                            Integration
                           and test plan        V&V            Integr ation
   Plan next phase                                                 test
                                                    Acceptance
                                            Service    test          Develop, verify
                                                                     next-level product

                                                                                                   32
FMs : A Review on SE..sw process
   Software specification
       The process of establishing what services are
        required and the constraints on the system’s
        operation and development
       Requirements engineering process
            Feasibility study
            Requirements elicitation and analysis
            Requirements specification
            Requirements validation

                                                        33
The requirements engineering process

  Feasibility   Requirements
    study       elicitation and
                    analysis
                                  Requir ements
                                  specification
  Feasibility                                       Requirements
    report                                           validation
                    System
                    models
                                  User and system
                                   requirements

                                                    Requirements
                                                     document



                                                                   34
Design process activities
   Architectural design
   Abstract specification
   Interface design
   Component design
   Data structure design
   Algorithm design


                             35
         The software design process
          Requirements
               ication
          specif

                                                           v
                                                 Design acti ities

Architectur
          al                        Interface             Component         Data         Algorithm
                      Abstract
   design                            design                design                e
                                                                          structur        design
                         ication
                    specif
                                                                           design




                     Software                                               Data
  System                             Interface           Component                       Algorithm
                         ication
                    specif                                                structure
          e
architectur                              ica
                                   specif tion                ication
                                                         specif                              ica
                                                                                        specif tion
                                                                        specification

                                                         oducts
                                                 Design pr




                                                                                                36
Software validation
   Verification and validation is intended to show that
    a system conforms to its specification and meets
    the requirements of the system customer
   Involves checking and review processes and
    system testing
   System testing involves executing the system
    with test cases that are derived from the
    specification of the real data to be processed by
    the system

                                                       37
             The testing process
 Unit
testing
                  Module
                  testing
                            Sub-system
                              testing
                                                   System
                                                   testing
                                                             Acceptance
                                                               testing


      Component              Integration testing              User
        testing                                              testing

                                                                       38
Testing stages
   Unit testing
         Individual components are tested
   Module testing
         Related collections of dependent components are tested
   Sub-system testing
         Modules are integrated into sub-systems and tested. The
          focus here should be on interface testing
   System testing
         Testing of the system as a whole. Testing of emergent
          properties
   Acceptance testing
         Testing with customer data to check that it is acceptable


                                                                      39
                             Testing phases

Requir ements              System                      System                   Detailed
specification            specification                 design                    design



                                           System                 Sub-system                   Module and
            Acceptance
                                         integration              integration                   unit code
             test plan
                                          test plan                test plan                    and tess



                         Acceptance                    System                 Sub-system
  Service
                            test                   integration test         integration test




                                                                                                    40
Software evolution
   Software is inherently flexible and can change.
   As requirements change through changing
    business circumstances, the software that
    supports the business must also evolve and
    change
   Although there has been a demarcation between
    development and evolution (maintenance) this is
    increasingly irrelevant as fewer and fewer
    systems are completely new

                                                      41
                  System evolution


Define system        Assess existing   Propose system   Modify
requirements            systems           changes       systems


                Existing                                  New
                systems                                  system




                                                                  42
   Software processes are the activities involved in
    producing and evolving a software system. They
    are represented in a software process model
   General activities are specification, design and
    implementation, validation and evolution (earlier
    mentioned as specification, development,
    validation and evolution)




                                                    43
   Generic process models describe the
    organisation of software processes
   Iterative process models describe the
    software process as a cycle of activities




                                                44
   Requirements engineering is the process
    of developing a software specification
   Design and implementation processes
    transform the specification to an executable
    program
   Validation involves checking that the
    system meets to its specification and user
    needs


                                               45
Software project management
   PM is concerned with activities involved in
    ensuring that software is delivered on time and on
    schedule and in accordance with the
    requirements of the organisations developing
    and procuring the software
   Project management is needed because software
    development is always subject to budget and
    schedule constraints that are set by the
    organisation developing the software


                                                     46
Management activities
   Proposal writing
   Project planning and scheduling
   Project costing
   Project monitoring and reviews
   Personnel selection and evaluation
   Report writing and presentations


                                         47
Conclusion
    Even if you don’t think formalism is needed for your
     project, it often helps to think in terms of a formalism to
     ensure that the informal (natural language) specification
     you write is as clear as possible.
    Formalisms often allow us to mathematically check
     specific properties of the specification.
    They can sometimes be used to automatically generate
     parts of the software system.
    Petri nets and Z are probably the two most popular
     formalisms at the present.



                                                                   48
The End of Chapter 1
    Thank you.




                       49

								
To top