croes@imec.be (Kris Croes) (01/16/91)
We are a research institute, and one of the ways to validate our methods, algorithms, heuristics,... is to build a program around it an try it out. Afterwards we want to use or integrate these programs with as less as possible rework. Normally, one can draw bubbles up to a certain level, and at a certain point, you are stuck. There is a part of the program that cannot be designed with SA/SD techniques. I think that developpers of adminstrative software have difficulties to accept this, because in my opinion, they are not confronted with this problem. I am adressing this article to all others --- if there are any reading this group. Where I am interested in, is wether there are techniques available to manage the research activities. E.g. what is a good way for developing a new heuristic for Graph Colouring. LET ME BE CLEAR: I DO NOT WANT TO START A DISCUSSION WETHER OR NOT ONE CAN DESIGN A COMPLETE PROGRAM TO THE LAST BIT. Any pointers to literature, or any suggestions on this topic are welcome. Thanks. Kris. -- -------- K. CROES - IMEC - Leuven - Belgium croes@imec.be The Demon King bites in your leg and you feel weaker.
pcg@spl27.spl.loral.com (Paul C George) (01/19/91)
In article <812@imec.UUCP>, croes@imec.be (Kris Croes) writes: |> We are a research institute, and one of the ways to validate our |> methods, algorithms, heuristics,... is to build a program around it |> an try it out. Afterwards we want to use or integrate these programs |> with as less as possible rework. |> |> Normally, one can draw bubbles up to a certain level, and at a certain |> point, you are stuck. There is a part of the program that cannot be designed |> with SA/SD techniques. I think that developpers of adminstrative software |> have difficulties to accept this, because in my opinion, they are not |> confronted with this problem. |> |> I am adressing this article to all others --- if there are any reading |> this group. |> |> Where I am interested in, is wether there are techniques available to |> manage the research activities. E.g. what is a good way for developing |> a new heuristic for Graph Colouring. I may be missing your problem, but it seems that Structure Charts allow design down to the module internal level. Automated tools support M-specs where one can go so far as to specify body logic up to the point of complete code. Bubble charts (aka Data Flow Diagrams) do only go down to a certian level, but many SA/SD tools (for example Mentor Graphics' Case Workstation) will convert them to structure charts, as they are the essence of SD. If the problem state/event or process activation logic, then the Hatley/Phirbahi extentions will help, and are supported by many tools. Similarly, Athena Systems (now Newthena?) Forsight supports ESML notation and simulation, with support for a parts library. For problems with complex concurrent state behavior, Harrel's State Charts may be helpfull. They are automated with full simulation in the i-Logix Statemate tool. For best support of reuse, object oriented techniques may help by enforcing encapsulation and clean interfaces. Graphically HOOD or Buhr/Booch notations may help design, and have automated support (though they are Ada orC++ oriented). If by Graph colouring you mean colored petrie nets (pardon my ignorance); Meta Software Corp has tools supporting SADT & ERD modeling as well as CPNs & simulation. If you are interested in verifying path, node, link, and conditional link coverage, the SRI tools (TCAT, TCAT-Path, TDGEN etc) may be of help as they instrument code, help generate test data and record coverage. Hope this grab bag gives some help.