000			03622nam a22004215i 4500
999			_c387584 _d387584
001			387584
003			ES-MaUEC
005			20230326131413.0
006			a||||fo|||| 00| 0
007			cr nn 008mamaa
008			220601s2020 sz | s |||| 0|eng d
020			_a9783031025501
024	7		_a10.1007/978-3-031-02550-1 _2doi
040			_aES-MaUEC _bspa _cES-MaUEC _dES-MaUEC
050		4	_aQA76.73.J38 _b2020 EB
100	1		_aCataño Collazos, Néstor _eautor _4aut _4http://id.loc.gov/vocabulary/relators/aut _9687647
245	1	0	_aJava Software Development with Event B : _bA Practical Guide _cby Néstor Cataño Collazos
250			_a1st edition 2020
264		1	_aCham _bSpringer International Publishing _c2020
300			_a1 recurso en línea (X, 89 páginas)
336			_atexto _btxt _2rdacontent
337			_aelectrónico _bc _2rdamedia
338			_arecurso electrónico _bcr _2rdacarrier
347			_aarchivo de texto _bPDF
490	0		_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.
988			_aSynthesis Collection of Technology_2020
650		7	_2embne _9322509 _aSoftware _xDesarrollo
650		7	_2embne _9151377 _aJava (Lenguaje de programación)
776	0	8	_iPrinted edition: _z9783031003400
776	0	8	_iPrinted edition: _z9783031014222
776	0	8	_iPrinted edition: _z9783031036781
856	4	0	_uhttps://go.openathens.net/redirector/universidadeuropea.es?url=https://doi.org/10.1007/978-3-031-02550-1 _zAcceso a este recurso digital (usuarios Universidad Europea de Madrid)
942			_2lcc _cLE
998			_b03/2023 _dz _esc