We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byTyshawn Munt
Modified over 3 years ago
© Colin Potts C6-1 Some future trends in requirements engineering Colin Potts Georgia Tech
© Colin Potts C6-2 Domain modeling & formal specs. l Domain modeling »Model a generic system or system template, not a specific system »Specify new systems by customizing the template l Formal specification »Use mathematically formal language to specify parts of a system »Prove properties of the specification to guarantee quality
© Colin Potts C6-3 Domain modeling l Use any engineering technique to specify a generic system »Typically use OOA, because it supports generalization directly l When specifying a system, refine the template »i.e. instantiate, specialize or modify
© Colin Potts C6-4 Domain modeling: Evaluation l Little experience »Several DARPA evaluation projects (C3I, etc.) l Domain modeling in practice has been confused with reuse of OO code »because domain modeling is a kind of reuse of analysis model fragments »and OO representations lend themselves to more abstract descriptions
© Colin Potts C6-5 Formal requirements specification l Mathematically rigorous specification »Rationale: critical systems failures will eventually lead to enforcement of engineering stds. l Several flavors of formal specification »Model-based specification is the most likely to achieve practical value »cf. Information modeling with richer constraints
© Colin Potts C6-6 Model-oriented formal specifications l Extension of ER modeling »ER diagrams are like type and function declarations »Cardinality constraints are logical rules »Other rules that cannot be shown in an ER diagram can be specified l Behavior is specified in operations »Preconditions and postconditions for each operation l Languages »Z, VDM, Fusion (OOA) method
© Colin Potts C6-7 Admissibility System states are legal configurations of attribute/relationship values What are the rules that specify these legal states? »And only these states »Need to specify these succinctly –Not as a transition diagram Conceivable states Admissible states
© Colin Potts C6-8 Model-based specification of behavior System behavior is modeled as a collection of state-changing operations »The preconditions of an operation state when it can occur –Not when it is triggered »Postconditions define the effects Permitted operation illegal operation
© Colin Potts C6-9 Simple Z example Container contents: Nat capacity: Nat contents < capacity schema declarations predicate/ invariant
© Colin Potts C6-10 Z operation schema Fill changes Container amount? : Nat contents + amount? < capacity contents' = contents + amount? precondition postcondition
© Colin Potts C6-11 Class exercise: Z modifications l As a class »Specify a new operation –Write the operation schema for dispense, an operation that dispenses fluid from the container »Add a new rule –Let the container have a warning light that goes on when the container becomes more than 80% full »What kinds of proof obligations arise in the two cases? »How does using model-based specification clarify your understanding of the (very trivial) problem domain?
© Colin Potts C6-12 Formal specification: evaluation l Maturity »Encouraging experiences in industrial projects, incl. –IBM (CICS) –Tektronix (oscilloscope embedded software) –Inmos (transputer FP microcode) l Advantages »Precision helps understand reqts and design implications l Limitations »Requires retraining (but not advanced math) l Trend »Increasing investment with need for dependable software & accountability for effects
Ontology-Based Computing Kenneth Baclawski Northeastern University and Jarg.
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 2.4 The Z Notation [Reference: M. Spivey: The Z Notation, Prentice Hall]
Software Engineering - Specifications 1 Specifications Specification document must be clear, complete and correct.
25 February 2009Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
1 Chapter 4 - Part 1 Software Processes. 2 Software Processes is: Coherent (logically connected) sets of activities for specifying, designing, implementing,
Software system modeling
Software Requirements Engineering
The Z Specification Language
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor Formal Methods in Software Engineering1.
Shaoying Liu Department of Computer Science
Basic Concepts in Component-Based Software Engineering
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der.
Introduction to Software Engineering
CS 425/625 Software Engineering System Models
UML CASE Tool. ABSTRACT Domain analysis enables identifying families of applications and capturing their terminology in order to assist and guide system.
©Ian Sommerville 2000Software Engineering, 6/e, Chapter 91 Formal Specification l Techniques for the unambiguous specification of software.
Describing Syntax and Semantics
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 10 Slide 1 Formal Specification.
© 2019 SlidePlayer.com Inc. All rights reserved.