Any math approaches to state management of complex objects?

Question

I usually use ASP.net web forms for GUI, maybe one of most "stateful" technologies. But it applies to any technology which has states. Sometimes forms are tricky and complex, with >30 elements and > 3 states of each element. Intuitive way of designing such a form usually works for 90%. Other 10% usually find testers or end-users:).

The problem as i see it that we should imagine a lot of scenarios on the same object, which is much harder than a consequence of independent operations.

From functional programming courses I know that best way is not to use state management and use pure functions and variable passing by value and all these stuff, which is greatly formalized. Sometimes, we cannot avoid it.

Do you use any math formalisms and approaches to state management of complex objects? Not like monads in Haskell, but which can be used in more traditional business applications and languages - Java, C#, C++.

It may be not Turing-complete formalism, but 99% will be great also:).

Sorry if it is just another tumbleweed question:)

Answer 1

It may be not Turing-complete formalism, but 99% will be great also:).

Sorry, but I'd rather provide NP-complete solution :)

Quick answer from me would be Test-Driven Approach. But read further for more.

The problem as i see it that we should imagine a lot of scenarios on the same object, which is much harder than a consequence of independent operations.

In such cases the decomposition (not only in computer science sense, but in mathematical too) is very useful. You decompose complex scenario in many simpler ones, which in turn can still be complex by themselves and can be decomposed further.

As a result of such a process you should end up with a number of simple functions (tasks) mostly independent of each ones. This is very important because then you can UNIT TEST those simple scenarios. Additionally, it is much easier and better to follow test-first approach which allows to see the decomposition in the very beginning of the development process.

Do you use any math formalisms and approaches to state management of complex objects?

To continue what I said, for me the most important thing is to make a good decomposition so that I can ensure the quality and being able to easily reproduce errors in an automated manner.

---

To give you an abstract example:

You have a complex scenario A. You always need to write at least 3 tests for each scenario: correct input, incorrect input and corner case(s).

Starting to write first test (correct input) I realize that the test becomes too complex.

As a result, I decompose scenario A into less complex A1, A2, A3. Then I start writing tests for each of them again (I should end up with at least 3*3=9 tests).

I realise that A1 is still too complex to test, so I decompose it again into A1-1, A1-2. Now I have 4 different scenarios (A1-2, A1-2, A2, A3) and 3*4=12 potential tests. I continue writing the tests.

After I am done. I start implementation, so all my tests pass. After that you have 12 proves that scenario A (more precisely its parts) works correctly. Additionally, you might write another 3 tests for the scenario A that combines all of its decomposed parts - this kind of testing is often (but not always!) can be seen as Integration testing.

Then let's assume a bug is found in scenario A. You are not sure which part it belongs to, but you suspect that it is related to A1-2 or A3. So you write 2 more tests for each of the scenario to reproduce the bug (write such a test that fails not meeting your expectations). After you have reproduced the bug you fix it and make ALL tests pass.

Now you have 2 more proves of correctly working system that ensures all the previous functionality is working the same way.

There are 2 main major problems with this approach IMO.

1. You need to write a lot of tests and support them. Many developers just do not want to do that.
2. Additionally, the process of decomposition is more art than science. Good decomposition will result in a good structure, tests and supportability while a bad one will result in a lot of pain and wasted time. And it is hard to tell if the decomposition is good or bad at first.

---

This process is called Test-Driven-Development. I find it to be the closest "formalization" of development process that plays nice between science and real world.

So I do not really talk about state here but rather behavior and proving it works correctly.

From personal experience, I should mention that ASP.NET WebForm is technically VERY hard to test. To overcome that, I would suggest to apply MVP pattern for ASP.NET WebForms.

As opposed to WebForms, ASP.NET MVC is so much easier to test. But still, you should have set of so called "services" (our scenarios) and (unit) test them separately, then test the UI integration in the environment close to Integration tests.

Answer 2

Use message-passing as an abstraction. Advantages:

1. The difficulty with complex state is complex interactions, which are especially hairy in concurrent systems like typical GUIs. Message-passing, by eliminating shared state, stops the complexity of state in one process from being infectious.
2. Message-passing concurrency has nice foundational models: e.g., the Actor model, CSP, both of which influenced Erlang.
3. It integrates well with functional programming: check out Erlang again. Peter van Roy's book *Concepts, Techniques, and Models of Computer Programming is an excellent text that shows the fundamental ingredients of programming languages, such as pure functions, and message-passing, and how they can be combined. The text is avilable as a free PDF.