Vous voulez être sûr que vos cadeaux seront sous le sapin de Noël à temps? Nos magasins vous accueillent à bras ouverts. La plupart de nos magasins sont ouverts également les dimanches, vous pouvez vérifier les heures d'ouvertures sur notre site.

Retrait gratuit dans votre magasin Club
7.000.000 titres dans notre catalogue
Payer en toute sécurité
Toujours un magasin près de chez vous

Retrait gratuit dans votre magasin Club
7.000.0000 titres dans notre catalogue
Payer en toute sécurité
Toujours un magasin près de chez vous

Magasins

Wishlist

Magasins

Wishlist

Chercher

Livres

Ebooks

Papeterie

Jeux

Cadeaux

Tous les produits

Dédicaces

Jobs

Articles

73,95 €

+ 147 points

Format

Livraison 1 à 2 semaines

Passer une commande en un clic

Payer en toute sécurité

Livraison en Belgique: 3,99 €

Livraison en magasin gratuite

Description

The 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.