Let's pull our heads out of our enterprisey IDEs, code generators, and J2EE containers. Consider this from Gregor Hohpe...
During our talk we mention an "advanced" technique that would not just render an image of the system model, but also examines the model and alerts the user about potential problems. It does so by applying known rules for "do's" and "don'ts" to the model. These rules could be as simple as "circles in your dependency graph are bad" or one of those sophisticated self-learning AI algorithms that we never quite understand...Which reminds me I forgot to mention a few weeks ago, the second edition of Concurrency: State Models and Java Programs is available. This is a really nice book whether you are a Java programmer or not. Chances are you are using concurrency if not distribution, or will soon.One of the key messages we are trying to highlight during our talk is the importance of mapping the captured data to a model that is suited to answering the questions you are interested in. This model can be a graph, a process or any other abstract representation of your system. Making a model is important for a number of reasons...
The second edition has more support for dynamic events and systems.
No comments:
Post a Comment