1 / 95

Specification Techniques and Formal Specifications

Specification Techniques and Formal Specifications. System models are abstract descriptions of systems whose requirements are being analysed. Objectives To explain why specification modelling techniques help discover problems in system requirements To describe

melba
Télécharger la présentation

Specification Techniques and Formal Specifications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Specification Techniques and Formal Specifications

  2. System models are abstract descriptions of systems whose requirements are being analysed Objectives • To explainwhy specification modelling techniques help discover problems in system requirements • To describe • Behavioural modelling (FSM, Petri-nets), • Data modelling and • Object modelling (Unified Modeling Language, UML)

  3. Formal Specification - Techniques for the unambiguous specification of software Objectives: • To explainwhy formal specification techniques help discover problems in system requirements • To describe the use of • algebraic techniques (for interface specification) and • model-based techniques(for behavioural specification)

  4. System modelling • System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers • Different models present the system from different perspectives • External perspective showing the system’s context or environment • Behavioural perspective showing the behaviour of the system • Structural perspective showing the system or data architecture

  5. System models weaknesses • They do not model non-functional system requirements • They do not usually include information about whether a method is appropriate for a given problem • They may produce too much documentation • The system models are sometimes too detailed and difficult for users to understand

  6. Model types • Data processing model showing how the data is processed at different stages • Composition model showing how entities are composed of other entities • Architectural model showing principal sub-systems • Classification model showing how entities have common characteristics • Stimulus/response model showing the system’s reaction to events

  7. 1. Context models • Context models are used to illustrate the boundaries of a system • Social and organisational concerns may affect the decision on where to position system boundaries • Architectural models show the a system and its relationship with other systems

  8. The context of an ATM system

  9. Process models • Process models show the overall process and the processes that are supported by the system • Data flow models may be used to show the processes and the flow of information from one process to another

  10. Equipment procurement process

  11. Semantic data models • Used to describe the logical structure of data processed by the system • Entity-relation-attribute model sets out the entities in the system, the relationships between these entities and the entity attributes • Widely used in database design. Can readily be implemented using relational databases • No specific notation provided in the UML but objects and associations can be used

  12. Software design semantic model

  13. Data dictionary entries Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included

  14. Object models • Object models describe the system in terms of object classes • An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object • Various object models may be produced • Inheritance models • Aggregation models • Interaction models

  15. Object models • Natural ways of reflecting the real-world entities manipulated by the system • More abstract entities are more difficult to model using this approach • Object class identification is recognised as a difficult process requiring a deep understanding of the application domain • Object classes reflecting domain entities are reusable across systems

  16. The Unified Modeling Language • Devised by the developers of widely used object-oriented analysis and design methods • Has become an effective standard for object-oriented modelling • Notation • Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section • Relationships between object classes (known as associations) are shown as lines linking objects • Inheritance is referred to as generalisation and is shown ‘upwards’ rather than ‘downwards’ in a hierarchy

  17. Behavioural models • Behavioural models are used to describe the overall behaviour of a system • Two types of behavioural model • Data processing models that show how data is processed as it moves through the system • State machine models that show the systems response to events • Both of these models are required for a description of the system’s behaviour

  18. Data Flow Diagrams • Data flow diagrams are used to model the system’s data processing • These show the processing steps as data flows through a system • IMPORTANT part of many analysis methods • Simple and intuitive notation that customers can understand • Show end-to-end processing of data

  19. Order processing DFD

  20. Data flow diagrams • DFDs model the system from a functional perspective • Tracking and documentinghow the data associated with a process is helpful to develop an overall understanding of the system • Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment

  21. State machine models • State Machine models the behaviour of the system in response to external and internal events • They show the system’s responses to stimuli so are often used for modelling real-time systems • State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another • Statecharts are an integral part of the UML

  22. Microwave oven model State machine model does not show flow of data within the system

  23. Microwave oven stimuli

  24. Finite state machines Finite State Machines (FSM), also known as Finite State Automata (FSA) are models of the behaviours of a system or a complex object, with a limited number of defined conditions or modes, where mode transitions change with circumstance.

  25. Finite state machines - Definition A model of computation consisting of • a set of states, • a start state, • an input alphabet, and • a transition function that maps input symbols and current states to a next state • Computation begins in the start state with an input string. It changes to new states depending on the transition function. • states define behaviour and may produce actions • state transitions are movement from one state to another • rules or conditions must be met to allow a state transition • input events are either externally or internally generated, which may possibly trigger rules and lead to state transitions

  26. Variants of FSMs • There are many variants, for instance, • machines having actions (outputs) associated with transitions (Mealy machine) or states (Moore machine), • multiple start states, • transitions conditioned on no input symbol (a null) or more than one transition for a given symbol and state (nondeterministic finite state machine), • one or more states designated as accepting states (recognizer), etc.

  27. Finite State Machines with Output (Mealy and Moore Machines) • Finite automata are like computers in that they receive input and process the input by changing states. The only output that we have seen finite automata produce so far is a yes/no at the end of processing. • We will now look at two models of finite automata that produce more output than a yes/no.

  28. Moore machine • Basically a Moore machine is just a FA with two extras. 1. It has TWO alphabets, an input and output alphabet. 2. It has an output letter associated with each state. The machine writes the appropriate output letter as it enters each state. This machine might be considered as a "counting" machine. The output produced by the machine contains a 1 for each occurrence of the substring aab found in the input string.

  29. Mealy machine • Mealy Machines are exactly as powerful as Moore machines • (we can implement any Mealy machine using a Moore machine, and vice versa). • However, Mealy machines move the output function from the state to the transition. This turns out to be easier to deal with in practice, making Mealy machines more practical.

  30. A Mealy machine produces output on a transition instead of on entry into a state. Transitions are labelled i/o where • i is a character in the input alphabet and • o is a character in the output alphabet. • Mealy machine are complete in the sense that there is a transition for each character in the input alphabet leaving every state. • There are no accept states in a Mealy machine because it is not a language recogniser, it is an output producer. Its output will be the same length as its input. The following Mealy machine takes the one's complement of its binary input. In other words, it flips each digit from a 0 to a 1 or from a 1 to a 0.

  31. Statecharts • Allow the decomposition of a model into sub-models (see a figure) • A brief description of the actions is included following the ‘do’ in each state • Can be complemented bytables describing the states and the stimuli

  32. Petri Nets Model • Petri Nets were developed originally by Carl Adam Petri, and were the subject of his dissertation in 1962. • Since then, Petri Nets and their concepts have been extended, developed, and applied in a variety of areas. • While the mathematical properties of Petri Nets are interesting and useful, the beginner will find that a good approach is to learn to model systems by constructing them graphically.

  33. The Basics • A Petri Net is a collection of directed arcs connecting places and transitions. • Places may hold tokens. • The state or marking of a net is its assignment of tokens to places. Place with token P1 Arc with capacity 1 T1 Place Transition P2

  34. Capacity • Arcs have capacity 1 by default; if other than 1, the capacity is marked on the arc. • Places have infinite capacity by default. • Transitionshave no capacity, and cannot store tokens at all. • Arcs can only connect places to transitions and vice versa. • A few other features and considerations will be added as we need them.

  35. The classical Petri net model A Petri net is a network composed of places ( ) and transitions ( ). t2 p2 t1 p1 p4 t3 p3 Connections are directed and between a place and a transition. Tokens ( ) are the dynamic objects. The state of a Petri net is determined by the distribution of tokens over the places.

  36. p1 Transition t1 has three input places (p1, p2 and p3) and two output places (p3 and p4). Place p3 is both an input and an output place of t1. p4 t1 p2 p3

  37. t1 t2 Enabling condition Transitions are the active components and places and tokens are passive. A transition is enabled if each of the input places contains tokens. Transition t1 is not enabled, transition t2 is enabled.

  38. t2 t2 Firing An enabled transition may fire. Firing corresponds to consuming tokens from the input places and producing tokens for the output places. Firing is atomic.

  39. Example

  40. Non-determinism Two transitions fight for the same token: conflict. Even if there are two tokens, there is still a conflict. t1 t2

  41. A collection of primitive structures that occur in real systems

  42. High-levelPetri nets • The classical Petri net was invented by Carl Adam Petri in 1962. Since then a lot of research has been conducted (>10,000 publications). • Since the 80-ties the practical use is increasing because of the introduction of high-level Petri nets and the availability of many tools. • High-level Petri nets are Petri nets extended with • color (for the modeling of attributes) • time (for performance analysis) • hierarchy (for the structuring of models, DFD's)

  43. Modeling States of a process are modeled by tokens in places and state transitions leading from one state to another are modeled by transitions. • Tokens represent objects (humans, goods, machines), information, conditions or states of objects. • Places represent buffers, channels, geographical locations, conditions or states. • Transitions represent events, transformations or transportations.

  44. red yr yellow rg gy green Example: traffic light

  45. red1 red2 yr1 yr2 yellow1 yellow2 rg1 rg2 gy1 gy2 green1 green2 Two traffic lights

  46. red1 red2 safe yr1 yr2 yellow1 yellow2 rg1 rg2 gy1 gy2 green1 green2 Two safe traffic lights

  47. Two safe and fair traffic lights red1 red2 safe2 yr1 yr2 yellow1 yellow2 rg1 rg2 gy1 gy2 safe1 green1 green2

  48. br red black rr bb Some definitions • current stateThe configuration of tokens over the places. • reachable stateA state reachable form the current state by firing a sequence of enabled transitions. • dead stateA state where no transition is enabled.

  49. (3,2) br rr bb\br red black (1,3) (3,1) rr br bb\br (1,2) (3,0) rr bb rr bb\br (1,1) br (1,0) • 7 reachable states, 1 dead state.

  50. Exercise: your life-cycle sleeping • How many states are reachable? • Is there a dead state? start stop active die dead

More Related