000 03878nam a22005415i 4500
001 978-3-031-02550-1
003 DE-He213
005 20240730163959.0
007 cr nn 008mamaa
008 220601s2020 sz | s |||| 0|eng d
020 _a9783031025501
_9978-3-031-02550-1
024 7 _a10.1007/978-3-031-02550-1
_2doi
050 4 _aT1-995
072 7 _aTBC
_2bicssc
072 7 _aTEC000000
_2bisacsh
072 7 _aTBC
_2thema
082 0 4 _a620
_223
100 1 _aCollazos, Néstor Cataño.
_eauthor.
_4aut
_4http://id.loc.gov/vocabulary/relators/aut
_981478
245 1 0 _aJava Software Development with Event B
_h[electronic resource] :
_bA Practical Guide /
_cby Néstor Cataño Collazos.
250 _a1st ed. 2020.
264 1 _aCham :
_bSpringer International Publishing :
_bImprint: Springer,
_c2020.
300 _aX, 89 p.
_bonline resource.
336 _atext
_btxt
_2rdacontent
337 _acomputer
_bc
_2rdamedia
338 _aonline resource
_bcr
_2rdacarrier
347 _atext file
_bPDF
_2rda
490 1 _aSynthesis Lectures on Software Engineering,
_x2328-3327
505 0 _aIntroduction -- An Overview of Event B -- Software Development of a Chat System with Event B -- The Poporo Social Network -- Conclusion -- Bibliography -- Author's Biography.
520 _aThe cost of fixing software design flaws after the completion of a software product is so high that it is vital to come up with ways to detect software design flaws in the early stages of software development, for instance, during the software requirements, the analysis activity, or during software design, before coding starts. It is not uncommon that software requirements are ambiguous or contradict each other. Ambiguity is exacerbated by the fact that software requirements are typically written in a natural language, which is not tied to any formal semantics. A palliative to the ambiguity of software requirements is to restrict their syntax to boilerplates, textual templates with placeholders. However, as informal requirements do not enjoy any particular semantics, no essential properties about them (or about the system they attempt to describe) can be proven easily. Formal methods are an alternative to address this problem. They offer a range of mathematical techniques and mathematical tools to validate software requirements in the early stages of software development. This book is a living proof of the use of formal methods to develop software. The particular formalisms that we use are EVENT B and refinement calculus. In short: (i) software requirements as written as User Stories; (ii) they are ported to formal specifications; (iii) they are refined as desired; (iv) they are implemented in the form of a prototype; and finally (v) they are tested for inconsistencies. If some unit-test fails, then informal as well as formal specifications of the software system are revisited and evolved. This book presents a case study of software development of a chat system with EVENT B and a case study of formal proof of properties of a social network.
650 0 _aEngineering.
_99405
650 0 _aMathematics.
_911584
650 0 _aComputer science.
_99832
650 0 _aSoftware engineering.
_94138
650 1 4 _aTechnology and Engineering.
_981479
650 2 4 _aMathematics.
_911584
650 2 4 _aComputer Science.
_99832
650 2 4 _aSoftware Engineering.
_94138
710 2 _aSpringerLink (Online service)
_981480
773 0 _tSpringer Nature eBook
776 0 8 _iPrinted edition:
_z9783031003400
776 0 8 _iPrinted edition:
_z9783031014222
776 0 8 _iPrinted edition:
_z9783031036781
830 0 _aSynthesis Lectures on Software Engineering,
_x2328-3327
_981481
856 4 0 _uhttps://doi.org/10.1007/978-3-031-02550-1
912 _aZDB-2-SXSC
942 _cEBK
999 _c85182
_d85182