1 / 20

Local variables

Local variables. Let var : Type = <expression1> in <expression2> Example: context Airport inv: Let supportedAirlines : Set (Airline) = self.arrivingFlights  collect(airLine) in ( supportedAirlines  notEmpty) and ( supportedAirlines  size < 500). Local Variable.

galena
Download Presentation

Local variables

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. Local variables Let var : Type = <expression1> in <expression2> • Example: context Airport inv: Let supportedAirlines : Set (Airline) = self.arrivingFlights  collect(airLine) in (supportedAirlines notEmpty) and (supportedAirlinessize < 500)

  2. Local Variable • Local variable can be used to represent a value of sub-expression using the let expression • Variable must be declared with a name, type, and an expression that specifies its value context person inv: let income : Integer = self.job.salary sum() in if isUnemployed then income < 100 else income >= 100 endif

  3. Local Variable context person inv: let income : Integer = self.job.salary  sum() carSize : Real = self.car.engine.maxPowerin if isUnemployed then income < 100 and carSize < 1.0 else income >= 100 and carSize >= 1.0 endif

  4. An Review of Constraints, OCL • Constraints: condition/restriction • Design level/code level constraints • Use of the OCL • class invariants, operation pre/post conditions, query • guards for state diagram • OCL as a language: formal, declarative, typed

  5. OCL Expressions • Context: any model elements(class, attributes, association) • Use of expressions: • Adding extra info • context init/derive, def • Constraints • context inv/pre/post • Query • context body

  6. OCL Types and Operations • Basic Types and Operations • Integer, Real, Boolean, String • Enum (user-defined types) • Collection types and Operations • Set, Bag, Ordered Set, Sequence

  7. OCL examples Context CustomerCard inv: goodThru.isAfter(Date::Now) Date CustomerCard goodThru: Date isAfter(t:Date): Boolean

  8. OCL examples Context CustomerCard inv: owner.programs->size()>0 0…* 0…* LoyaltyProgram Customers programs 1 owner cards 0…* CustomerCard

  9. Exercise • A Smokestack is like a Stack. It is last-in-first-out (LIFO), but it has a maximum depth. If the smokestack is full, pushing a new element on will result in the bottommost element being deleted (turned to smoke). • • Operations are push, pop, top, isEmpty, isFull.

  10. Class Diagram

  11. OCL Constraint System • context Smokestack • invmaximumDepth: s->size() <= maxSize • post Smokestack (m:Integer): maxSize = m -- constructor • post push(e:Object): if s->size()<maxSize • then s=s@pre->prepend(e) • else s=(s@pre->subSequence(1,maxSize-1))->prepend(e) • pre pop(): s->notEmpty() • post pop(): s=s@pre->subSequence(2,s@pre->size) • pre top(): s->notEmpty() • post top(): result = s->first() • postisEmpty(): result = s->isEmpty() • postisFull(): result = s->size() = maxSize

  12. Job Title:Research Computer Scientist, AST, Computer Research and Development Department:National Aeronautics and Space Administration (NASA) Agency:Langley Research Center Job Announcement Number:LA13D0064

  13. Job Description Performs research directed toward discovering, disseminating, and applying new or expanded knowledge in system safety assurance. Research may include, evaluating existing formal verification technology to determine the extent to which they can be applied to the analysis of safety-critical aerospace systems of interest to NASA; conducting research to create, develop, and integrate innovative formal techniques and verification tools for the analysis, design, and implementation of critical systems and operational concepts; conducting research to create, develop, and integrate automated verification techniques and tools to analyze the effects of changes in software and formal models on safety-critical systems; verifying and validating algorithms, software implementations, and operational concepts with respect to safety requirements; proving mathematical theorems in a theorem prover, including theorems from both pure and applied mathematics, that will be used in the formal verification of safety-critical systems; developing formal models of software-intensive aerospace systems including failure, disturbance, and degradation behaviors with the intent of verifying and validating robust system performance and; planning and conducting interdisciplinary investigations on advanced safety-critical systems such as unmanned systems, autonomous systems, embedded systems, and distributed systems.

  14. Requirement Demonstrated experience with formal verification technology such as theorem provers, software verification tools, rewriting engines, satisfiability solvers, and/or model checkers; experience with application of formal methods to mid-size problems.

  15. Formal Specification Techniques Benefits at the requirements phase • Precision and lack of ambiguity enable effective communication • FSTs assist in the early discovery of incomplete and ambiguous specifications • FSTs enable rigorous analysis • verification • validation via challenges • enhance reviews

  16. The role of FSTs in Software Engineering A Formal Specification Technique (FST) consists of a formal specification language and mechanisms for deriving consequences from statements in the language FSTs can be used to: • Prove that a specification is implementable • Prove that an implementation satisfies its specification • Prove properties of system without executing them

  17. Using FSTs to support design and implementation Benefits at the design phase • Supports effective decomposition of systems and precise specification of interfaces • Supports delaying design decisions through data and behavior refinement FSTs and validation • Specifications can be used to generate effective black box test cases • At requirements and design level, specifications can be animated/executed or statically analyzed FSTs and documentation • Precise, abstract, and analyzable statements of behavior

  18. Types of properties that can be investigated with FSTs • Correctness: desired functionality; a refinement is consistent with its specification • Safety: a model/specification does not allow undesired behavior • Liveness: a model/specification will eventually do certain desired things • Security: unauthorized access to sensitive data and programs are not permitted by model • Timeliness: timing constraints

  19. Limitations of Formal modeling of software • Formal specifications: • Can say too little or too much; • Can be wrong! • Proofs can be wrong • A formal model is at best an approximation of the real world; mathematical models cannot account for real-world behavior with perfect accuracy • Formal models make assumptions about reality; if these are violated then behavior cannot be predicted using the model • Formal proofs do not correspond to evidence needed to convince human reviewers

  20. Formal specification myths • FSTs eliminate the need for testing • FSTs eliminate the need for natural language descriptions • You need a PhD in mathematics to understand FSTs • FSTs guarantee correctness • Only highly critical systems benefit from FSTs • FSTs increase cost of development • FSTs are time-consuming • FSTs lack tools

More Related