Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>It may be not Turing-complete formalism, but 99% will be great also:).</p> </blockquote> <p>Sorry, but I'd rather provide NP-complete solution :)</p> <p>Quick answer from me would be <a href="http://en.wikipedia.org/wiki/Test-driven_development" rel="nofollow noreferrer">Test-Driven Approach</a>. But read further for more.</p> <blockquote> <p>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.</p> </blockquote> <p>In such cases the <strong>decomposition</strong> (not only in <a href="http://en.wikipedia.org/wiki/Decomposition_(computer_science)" rel="nofollow noreferrer">computer science</a> sense, but in <a href="http://en.wikipedia.org/wiki/Functional_decomposition" rel="nofollow noreferrer">mathematical</a> too) is very useful. You decompose <strong>complex scenario</strong> in many <strong>simpler ones</strong>, which in turn can still be complex by themselves and can be decomposed further.</p> <p>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 <a href="http://en.wikipedia.org/wiki/Unit_testing" rel="nofollow noreferrer">UNIT TEST</a> those simple scenarios. Additionally, it is much easier and better to follow <a href="http://en.wikipedia.org/wiki/Test-driven_development" rel="nofollow noreferrer">test-first approach</a> which allows to see the decomposition in the very beginning of the development process.</p> <blockquote> <p>Do you use any math formalisms and approaches to state management of complex objects?</p> </blockquote> <p>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.</p> <hr> <p>To give you <strong>an abstract example</strong>: </p> <p>You have a <strong>complex scenario</strong> <code>A</code>. You always need to write <strong>at least 3 tests</strong> for each scenario: correct input, incorrect input and corner case(s).</p> <p>Starting to write first test (correct input) I realize that the <strong>test becomes too complex</strong>. </p> <p>As a result, I <strong>decompose scenario</strong> <code>A</code> into less complex <code>A1</code>, <code>A2</code>, <code>A3</code>. Then I start writing tests for each of them again (I should end up with at least 3*3=9 tests).</p> <p>I realise that <code>A1</code> <strong>is still too complex</strong> to test, so I <strong>decompose it again</strong> into <code>A1-1</code>, <code>A1-2</code>. Now I have 4 different scenarios (A1-2, A1-2, A2, A3) and 3*4=12 potential tests. I continue writing the tests. </p> <p>After I am done. I <strong>start implementation</strong>, so all my tests pass. After that you have 12 proves that scenario <code>A</code> (more precisely its parts) works <strong>correctly</strong>. Additionally, you might write another 3 tests for the scenario <code>A</code> that combines all of its decomposed parts - this kind of testing is <em>often</em> (but not always!) can be seen as <a href="http://en.wikipedia.org/wiki/Integration_testing" rel="nofollow noreferrer">Integration testing</a>.</p> <p>Then let's assume a bug is found in scenario <code>A</code>. You are not sure which part it belongs to, but you suspect that it is related to <code>A1-2</code> or <code>A3</code>. So you <strong>write 2 more tests</strong> for each of the scenario to <strong>reproduce the bug</strong> (write such a test that fails not meeting your expectations). After you have reproduced the bug you fix it and make ALL tests pass. </p> <p>Now you have 2 more proves of correctly working system that ensures all the previous functionality is working the same way.</p> <p>There are 2 main major problems with this approach IMO.</p> <ol> <li>You need to write a lot of tests and support them. Many <strong>developers just do not want</strong> to do that. </li> <li>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 <strong>hard to tell if the decomposition is good or bad</strong> at first.</li> </ol> <hr> <p>This process is called <strong>Test-Driven-Development</strong>. I find it to be the <strong>closest "formalization" of development process that plays nice between science and real world</strong>.</p> <p>So I do not really talk about state here but rather behavior and proving it works correctly.</p> <p>From personal experience, I should mention that ASP.NET WebForm is technically VERY hard to test. To overcome that, I would suggest to <strong><a href="http://webformsmvp.codeplex.com/" rel="nofollow noreferrer">apply MVP pattern for ASP.NET WebForms</a></strong>.</p> <p>As opposed to WebForms, <strong>ASP.NET MVC is so much easier</strong> 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.</p>
    singulars
    1. This table or related slice is empty.
    1. POAny math approaches to state management of complex objects?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USDmytrii Nagirniak
    1. USDmytrii Nagirniak
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COi'm sorry, but i will not write tests for all gui in real-life projects. and if gui is complex, than tests will be complex twice. and that is not formalism at all, 'cause i still have no formal tools to verify my steps.
      singulars
      1. PO
      1. USrudnev
    2. CO`i will not write tests for all gui in real-life projects` - I said to write unit tests, not GUI tests. `tests will be complex twice` - decompose complexity as I described. It is not formalism, but you DO have tools to verify the steps: Unit Testing Frameworks (nUnit, xUnit, MbUnit, Specs etc - you name it).
      singulars
      1. PO
      1. USDmytrii Nagirniak
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload