Hello Debasish,
My name is Tim Stewart and I'm a software developer. I am very excited about your current book and would be happy to review it if you still need reviewers.
I was just rereading Barbara Liskov's "Program Development in Java" and a few concepts finally clicked together in my head. They seem to be relevant to your book. There is a 99.9999% chance that your book already touches on these concepts and how they fit together but just in case it doesn't (and you find them to be relevant), I thought I'd drop you this note.
1. When designing a system, a domain model can be represented as a graph where each entity in the domain is a node in the graph, and relationships between entities are modeled as edges between nodes (e.g. you might have an Account node and an Invoice node connected by a directed "paid" edge to represent paid invoices in an account).
2. Each node represents a set of entities (e.g. the Account node represents all Account objects in the system).
3. An edge between two nodes represents a function from one entity to another (e.g. invoiceAccount : Invoice > Account).
4. Some functions (derived from edges) have inverses (conceptually at least) (e.g. accountInvoices : Account > Set[Invoice]).
Once I start viewing my domain in terms a graph of sets, and functions over sets, I can bring in all sorts of mathematical ideas to reason about my system. I can use existential and universal quantifiers, functional composition to traverse relations, set theory, graph theory, and so on. Some of these ideas can be used to express Hoare Triples when specifying behavior of functions. I would think (though I'm not sure) that Category Theory might also play a valuable role.
I also just reread Alexander Stepanov's book, "From Mathematics to Generic Programming" and he talks about the power of Abstract Algebra in programming (e.g. in order to be truly generic, you must be very specific about what your algorithms depend on from the types it operates on). Using Abstract Algebra we can see that an Invoice might be a Monoid in the sense that you may be able to combine two invoices into one. Identifying what axioms a set and its operations support can help you reason about your system using very precise language. For example, knowing that an operation is commutative adds more flexibility around parallelizing that operation across a set of objects.
I think that all these mathematical ideas dovetail very nicely with the area of denotational semantics but I haven't explored the connections very deeply yet.
Thanks for reading this!
Tim
