From lechner@cs.uml.edu Sat Mar 12 01:37:05 2005 From: Bob Lechner Subject: I too have that dream! :-) To: ilia@ibissoft.se RJLRef: $PH/06f522/ITooHaveThatDream.2IBider060312.txt "This practice has been abandon a long time ago." - Are you sure? I believe {control} state models are a natural evolution from those flowchart diagrams, up thru object life cycles. Bohm and Jacopini showed how to construct structured programs from arbitrary flowcharts. Wirth used recursive descent state models in syntax diagram form to guide his Pascal compiler. And database code generators inferred specs from EERD's [including data types declared with comments :-)] long before UML class diagrams complicated the picture. Then distributed systems complicated the picture further, which led UML state modelers to focus on asynchronous events and ignore the sequential control flow within (but interleaved with other) process threads. Many years ago I worked on Charles Bachman's ADF (Architecture Definition Facility) prototyping tool, a PL/1-based interpreter of his data structure diagrams and its network database extension with a single string data type (a la MUMPS). At the same time I worked with Bill Stallings on a state-modelling language and interpreter for Honeywell minicomputers (when memory was the bottleneck). The result was compact code that could be downloaded (a la .java) and interpreted to run a mini-OS. It took years (and inspiration from Shlaer-Mellor's 1992 Object Life Cycle text and from iLogix's StateMate) before I discovered how to integrate these two approaches Result: a mini-Model-Driven-Architecture framework. [Prototype: http://www.cs.uml.edu/~lechner/COOL] The CleanRoom experience of Witt/Baker/Merritt led to their book "Software Architecture and Design" whose Part 1 claimed a seamless approach to formal requirements in operational specs, but it came with no case studies of how to compose a hierarchy of routines with local pre-/post-condition specs. Then they dropped the ball and ignored their own formalism in part 2 on concurrent and distributed systems. The point is: I believe it's a lot easier to model operational specifications in event-driven concurrent systems than it is to write declarative specifications of the same distributed applications. The key is to divide and conquer by making hierarachically decomposing state models at runtime by using an event-based call stack per interpreter at each site). [Caveat: My applications are tools for programmers (me) for developing prototypes, so I don't worry much about interpreting user requirements. I have enough problems understanding my own :-)] Bob Lechner Prof Emer./Adjunct Computer Science Dept UMass Lowell Ilya Bider wrote (050306 to re-online): > There is a perception that using formal methods have at least two advantages: > > 1. It gives a possibility for formal verification > 2. It is better suited for developing a software system. > > However, as it stands now, there are some hinders for using these > advantages in the business software development: > > 1. Only internal consistency of the model can be verified formally. In the > field of business application development the main problem is the adequacy > of a specification to the business reality rather than its internal > consistency. What is the point to have an internally consistent model when > it does not represent the reality properly? This problem exists not only > for formal methods, but informal as well. When stakeholders say that they > understand and accept the specification, it does not mean they understand > what does it mean working with such a system, as it may completely change > their business reality (some examples from our own experience can be seen > in http://www.ibissoft.se/publications/experience.pdf). > > 2. Creating a formal specification might be quite a tedious task. After > that one should implement this specification in some programming > language/tool which means doing the job twice, especially, considering that > the specification can be not adequate (see one above). I remember time when > programing has been done in too steps. Some people where drawing block > diagrams, the others were doing coding (remember also the idea of JSP that > has never made it to practice). This practice has been abandon a long time ago. > > Is there any way to avoid above difficulties and make formal specification > work in the business application development? I believe there is. I still >>> > dream about executable specifications (or executable models, whichever you <<< > like best). I talk to the stakeholders informally, go home and create a > formal specification, and next day run it as a system (or emulation of one) > to the stakeholders. > >>> > Is there any way to realize this dream, at least partially? I believe there <<< > is, In the late 80th's beginning of 90th's there were a number of so-called > 4th generation tools that partially implemented the idea for the generation > of business applications valid for that time. I am in no way suggesting > that they are suitable for the current generation of business applications, > but, I think that the general direction was right. Most unfortunately, this > direction was abandoned in the favor of UML modeling on one hand, and > low-level programming, e.g., JAVA on the other.