From requirements to specification Specification is a refinement of requirements Can be included together as Software Requirements Specifications (SRS)

Slides:



Advertisements
Similar presentations
Principles of Engineering System Design Dr T Asokan
Advertisements

Based on: Petri Nets and Industrial Applications: A Tutorial
PROTOCOL VERIFICATION & PROTOCOL VALIDATION. Protocol Verification Communication Protocols should be checked for correctness, robustness and performance,
Interaction Modeling for Testing We would generate the test cases based on our understanding of the interactions that may happen. The source is, again,
Project management Project manager must;
Introduction to Software Testing Chapter 2.6 Graph Coverage for Use Cases Paul Ammann & Jeff Offutt
Requirement Analysis and Specification Mr. Manoj Kumar Kar.
IE 469 Manufacturing Systems
Introduction to Software Testing Chapter 2.6 Graph Coverage for Use Cases Paul Ammann & Jeff Offutt
1 Chapter 4 Dynamic Modeling and Analysis (Part I) Object-Oriented Technology From Diagram to Code with Visual Paradigm for UML Curtis H.K. Tsang, Clarence.
Sequence Diagrams. Introduction A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of methods in each object, and.
1 Chapter 4 Dynamic Modeling and Analysis (Part I) Object-Oriented Technology From Diagram to Code with Visual Paradigm for UML Curtis H.K. Tsang, Clarence.
Chapter 12 ATM Case Study, Part 1: Object-Oriented Design with the UML
Interaction Diagrams Activity Diagram State Machine Diagram
28.2 Functionality Application Software Provides Applications supply the high-level services that user access, and determine how users perceive the capabilities.
Introduction To System Analysis and Design
ECE 331 – Digital System Design
Systems Analysis and Design in a Changing World, 6th Edition
Advanced Behavioral Modeling
Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory.
Time, Clocks, and the Ordering of Events in a Distributed System Leslie Lamport (1978) Presented by: Yoav Kantor.
Timed UML State Machines Ognyana Hristova Tutor: Priv.-Doz. Dr. Thomas Noll June, 2007.
PETRINETS Nipun Devlekar Zauja Lahtau. PETRINETS DEFINITION : DEFINITION :  PETRINET (place/ transition net): a formal, graphical, executable technique.
Dynamic Black-Box Testing Part 2
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 8: Modelling Interactions and Behaviour.
Chapter 5: Specification Yuanfang Cai CS751 Jan 29, 2003.
UML’s StateChart FSM, EFSM in UML Concurrent states Tool support.
1 Object-Oriented Modeling Using UML (2) CS 3331 Fall 2009.
Interaction Modeling. Introduction (1) Third leg of the modeling tripod. It describes interaction within a system. The class model describes the objects.
Introduction to Formal Methods Based on Jeannette M. Wing. A Specifier's Introduction to Formal Methods. IEEE Computer, 23(9):8-24, September,
- 1 - Embedded Systems - SDL Some general properties of languages 1. Synchronous vs. asynchronous languages Description of several processes in many languages.
CY2003 Computer Systems Lecture 7 Petri net. © LJMU, 2004CY2003- Week 72 Overview Petri net –concepts –Petri net representation –Firing a transition –Marks.
Ch. 2. Specification and Modeling 2.1 Requirements Describe requirements and approaches for specifying and modeling embedded systems. Specification for.
Black Box Testing Techniques Chapter 7. Black Box Testing Techniques Prepared by: Kris C. Calpotura, CoE, MSME, MIT  Introduction Introduction  Equivalence.
9-1 © Prentice Hall, 2007 Chapter 9: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
Use Case Driven Analysis Requirements Use Case Use Case Description System Sequence Diagram Chapter 5.
1 Kyung Hee University Statecharts Spring Kyung Hee University Specifying Objects’ Behaviour  Interaction diagrams show message-passing behaviour.
Petri Nets Lecturer: Roohollah Abdipour. Agenda Introduction Petri Net Modelling with Petri Net Analysis of Petri net 2.
Petri Nets Invented by Carl Adam Petri in 1962 Concurrent systems with timing problems  Synchronization, race problem, deadlock A petri net consists of.
Modelling by Petri nets
1 Graph Coverage (6). Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Section
UML’s StateChart FSM, EFSM in UML Concurrent states Tool support.
CS212: Object Oriented Analysis and Design Lecture 34: UML Activity and Collaboration diagram.
Week 3: Requirement Analysis & specification
CSCI1600: Embedded and Real Time Software Lecture 11: Modeling IV: Concurrency Steven Reiss, Fall 2015.
School of Computer Science & Software Engineering
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
7-1 © Prentice Hall, 2007 Topic 7: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 10: Statecharts.
Requirement Analysis SOFTWARE ENGINEERING. What are Requirements? Expression of desired behavior Deals with objects or entities, the states they can be.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
Winter 2007SEG2101 Chapter 121 Chapter 12 Verification and Validation.
CS 145A Protocols Netlab.caltech.edu/course. Misc. Extension Extension Textbooks Textbooks.
From requirements to specification Specification is a refinement of requirements Can be included together as Software Requirements Specifications (SRS)
Systems Analysis and Design in a Changing World, Fourth Edition
Analysis Classes Unit 5.
Paul Ammann & Jeff Offutt
Advantages of FSM Their simplicity make it easy for inexperienced developers to implement with little to no extra knowledge (low entry level)
ATM OO Design and Implementation Case Study
Dynamic Modeling of Banking System Case Study - I
Dynamic Modeling of Banking System Case Study - II
State Machine Diagrams
UML’s StateChart FSM, EFSM in UML Concurrent states Tool support.
Use Case Modeling - techniques for detailing use cases
Paul Ammann & Jeff Offutt
Dynamic Modeling Lecture # 37.
Using Use Case Diagrams
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Interaction Modeling Extracted from textbook:
Real-Time Structured Analysis and Design Technique (RSTAD)
Presentation transcript:

From requirements to specification Specification is a refinement of requirements Can be included together as Software Requirements Specifications (SRS) Elaborate on the WHAT? the software system is supposed to do – As opposed to HOW it will do it – Should not be very constraining – Leave the details to the design

Software modeling Modeling techniques – visual, executable, general, readable, ….. Modeling – Behavior: Finite state machine (FSM), Petri net (PN), Sequence diagram, Activity diagram, and other UML diagrams – Data: Entity relationship diagram (ERD) – Process: Data flow diagram (DFD), Decision table, decision tree

The Finite State Machine Model (FSM) Used to describe: – State-based behavior of a process within a software systems. – Whole system as one process. FSM is used when the number of states the process can be in is small, and the next state of a process is determined by its current state and the inputs applied to the process. Typically, the process behavior is be described by the next process state and the output the process delivers after accepting an input.

Algebraic definition of an FSM

Properties of an FSM model Completeness Determinism Fully connected Strongly connected Minimal Can be verified

Complete FSM An FSM is said to be complete or completely specified, if and only if, at each state, there exists a transition for each input i   I. In other words, the FSM should react to every input at every state, and this reaction should be captured and specified in the model.

Complete FSM To produce a robust software system, it is desirable to specify what to do when both valid (good) and invalid (bad or unexpected) inputs are applied at each state of the system. Specification completeness would allow the implementation of a robust process, a process capable of dealing with both correct and wrong inputs.

Deterministic FSM An FSM is said to be deterministic, if and only if, at any state, the reaction to an input is unique and unambiguously determined. Uniqueness means that for the same input at the same state, the FSM should move to the same next state and delivers the same output, any time it executes.

Deterministic FSM It is extremely desirable that an FSM modeling a software process be deterministic. A software implementation must be deterministic, since a user, at the same state, would like to obtain the same result any time the same request (input) is present. This property is desirable also for any user- oriented systems (i.e., a vending machine, a telephone system,...).

Strongly connected FSM An FSM is said to be strongly connected, if from any state, we can reach any other state of the FSM either immediately by executing one or more transitions. The strong connectedness feature is desirable for software processes. A state that is not reachable from any other state means that the process is somehow disconnected or discontinued. Therefore, one part of the process may be useless since it is unreachable.

Fully connected FSM An FSM is said to be fully connected, if from any state of the FSM, we can reach each of the other states by executing one transition. This requirement is very restrictive and infeasible, and is normally not desirable in software processes. Think about it for a user interface?

Minimal FSM An FSM is said to be minimal, if there exists no other equivalent FSM with less number of states or transitions. The minimality property is desirable for both software and hardware (digital) systems. Implementing a non-minimal FSM implies wasting development efforts on a non-reduced and somehow redundant specification. This definition of minimality assumes that all transitions are of equal complexity.

Example Describe the FSM in both the algebraic and tabular forms. Can you describe in English what does this FSM specify? Add the necessary transitions and states to the FSM diagram. Is the FSM complete and deterministic? why? if incomplete, can you suggest a modification to complete it.

Limitations of the FSM Conditional behavior specification Time specification Data manipulation specification Concurrency specification The Extended FSM – EFSM

Timing and Timeout Specification We want to specify that if at a state S no input is present within t time units, a transition should take place and an output should be delivered. – This situation would occur in many real-time processes, and in user-oriented interfaces and systems. We would like to have certain delayed transitions, in which a time delay is specified instead of an input symbol. Presence of an input symbol or time delay is mutually exclusive.

Conditional Transitions To specify that, at a given state S, in addition to the availability of an input symbol, certain predicate(s) should evaluate to True – Predicated or conditional transitions. – Transition takes place only if the predicate evaluates to true. Modified definition: EFSM is said to be deterministic, if at the same state, for the same input and the same predicate, the same transition (next state and output) must occur.

Is this deterministic?

Variable Manipulation If at given state of the FSM, the reaction to the next input symbol must change a certain variable value needed in future transitions (i.e., in a predicate evaluation). For example, in a user interface driven process, at the logon state, the reaction to a bad login input may depend on the number of times a bad login input was performed earlier. – A variable holding a counter of the number of bad logins is needed.

Concurrency Specification Due to its inherently sequential nature, a basic finite state machine cannot model concurrent behaviors that may be needed to describe complex concurrent applications. Extensions to the FSM were added in the UML statechart diagram to model concurrent execution by specifying concurrent substates.

States: idle state (s1), the wait-for-pin state (s2), the start-selection state (s3), and the card-confiscated state (s4). Inputs: the client’s card (i1), and the PIN code (i2). Outputs: the screen to get the PIN (sc1), the waiting for PIN timeout message (o1), the invalid PIN error message (e1), the card confiscated message (e2), and the start transaction selection screen (sc2). Predicate P1 evaluates to true if the number of trials did not exceed the specified limit, and predicate P2 evaluates to true if the entered PIN code is valid. Only one variable to count the number of trials is needed (v1).

Example Suppose that at any state (except the initial idle state) if we do not receive an input within 10 time units, we want the system to be blocked for 5 time units and then move to the locked state again. Add the necessary transitions and states to the FSM diagram.

Example Partial behavior of ATM: – “First the user inserts the bank card in the ATM’s card reader. – Then, the ATM expects the user to enter the PIN within 20 seconds, otherwise the ATM will beep and eject the card. – If the PIN is valid, the user is allowed to proceed with a choice of banking transactions. – Otherwise if the PIN is invalid, the user can retry for a maximum of two more trials. – After 3 wrong trials, the card is confiscated by the ATM, and the user has to contact the main branch.”

Example Given the following English specification involving a distributed system of 3 CFSMs corresponding to 3 interacting processes. “The user process (UP) requests a data item from the server process (SP). The server process directs any request to the database process (DP) which returns either with a data item or an error message indicating that the requested item is not available. Once the SP receives the data item (data), it increments a counter (c) of serviced request by 1 and passes the data item to the UP. However, if the SP receives an ‘item not available’ (nav) message from the DP, it tries again one more time after the elapse of 2 seconds. If for the second time, it receives the ‘item not available’ (nav) message, it returns back to the UP with the message ‘item not available’ (nav).”

The Petri Net model Introduced by Carl Petri in Powerful modeling technique with strong mathematical foundation. – Verification of the model properties is facilitated. Algebraic and graphical representation Executable and verifiable using available tools

Algebraic definition of a PN

Graphical representation of a PN

PN Example Places: p1, p2, p3 Transitions: t1, t2 Backward and Forward Arcs Tokens: 2 tokens (initially) – Initial marking: (1, 0, 1)

t1, t4 are forking transitions t3 is a joining (synchronizing transition)

Analysis of a PN model Structural properties: invariant analysis – Place invariants – Transition invariants Dynamic properties: enumerative analysis – Reachability graph

PN invariants Transition invariants: – A sequence of transition that leads back to the same token distribution (the initial state) Desirable properties for cyclic systems C (the incidence matrix) = B – F M’ = M + C  and M’ = M => C  = 0 Solve for C (  1  2  3 …  t ),  = 0 – Can have more than one transition invariant

PN invariants Place invariants: – A subset of places in which the number of tokens remains constant – Conservative PN: the number of tokens in the whole net remains constant – Can have more than one place invariant – Solve  C = 0, where the  = (  1  2 …  p )

Enumerative analysis

Extensions to the PN model Inhibitor Arc PN Predicate PN Timed PN Colored PN Numeric PN Probabilistic PN Fuzzy time PN …

Example – Modeling requirements In a request handling system, the handler must immediately process an incoming request once it is received. The processing takes between 5 and 10 seconds to complete. Once a request is handled, the system must be able to handle new requests immediately. The system should keep track of the number of handled requests.

p2 p3 is a place invariant No transition invariants