RE: [tamie] EBA

I am always a little suspicious when we get a new one-letter variant (EBA) of an existing design framework (EDA), but I chased the link that was provided and found the remarks plausible from a “unit testing” point of view. And the point about needing to be clear about the distinction between “events” and “notification” was useful. However, I am unconvinced that EBAs have good results because “they minimize the relationships between the parts of a system”.

What the author calls “minimization of relationships at design time” (reflected in few, if any, associations among classes in designs) turns out to more accurately be deferring the relationship of parts from design time to runtime. Instead of “design/compile time” linking we are treated to runtime binding among the results of builders.

I think the advantage for testing is that no system level assertions can be tested because none are made. System testing becomes something that can only be done by looking at execution traces which reflect what patterns of events occur that triggered the notifications that directed the system behavior. Without some “interaction constraints,” testing has to involve a combinatorially exhaustive linking/binding of all possible events and notification patterns to find what happens in overall system behavior.

That is why I think our emerging approach to testing has a nice balance between simplicity of unit tests, but control of system tests. BP descriptions given by LTSes do provide the interaction level contracts or assertions that constrain the focus for system testing, or at least that is a direction that we are investigating.

In addition, our approach makes it clearer how monitoring can be a useful part of the overall system. When events and their associated notifications fall outside the constraints found in the LTS interaction patterns, then something is badly amiss in system behavior (something like an exception being generated from above rather than bubbling up from below). This means many variations in behavior within the “Asynchronous Inter-Action Oriented Peer-to-Peer programming model.” ™ JJ Dubray “can be ignored (except as input to process redesign and optimization system paths) so long as the contract in LTS and QOS aspects is honored.

From OASIS XML daily news July 2:

interesting comments on the testability of event-based systems, and their suitability to large-scale systems, beyond the usual UI application.

Jacques

---------------------------------------------------------------

Event-Based Architectures (EBAs) simplify system design, development, and testing because they minimize the relationships between the parts of a system... What Is an EBA? An EBA is an architecture based on parts that interact solely or predominantly using event notifications, instead of direct method calls. An "event notification" is a signal that carries information about an event that was detected by the sender. While you're probably familiar with events like button clicks, events can be defined to include almost any conditions or occurrences you can think of.

Notifications can be used to carry any domain-specific information you want, and in any type of system -- embedded, GUI-based, distributed, or other. There are different ways to deliver notifications, but the most common technique uses an indirect method call that is made through a pointer initialized at runtime. At design time, the compiler is unaware of what object (and perhaps even what type of object) the pointer will be referencing when the call is made. In an EBA, each part emits signals related to its internal state and reacts to signals received from other parts. This simple input/output model has important consequences: Each part can be developed and tested in isolation from the rest of the system, because it knows nothing about the other parts. In a well-designed EBA, the relationship of complexity versus size tends to be more linear than exponential, so the larger the system is, the better off you are with an EBA, compared to other conventional approaches. The larger a system gets, the more you can benefit from Event-Based Architectures. The individual parts, be they classes or components, have little or no type coupling to the rest of the system. This is especially important for testability.

EBAs are eminently testable. They can be tested incrementally and can be developed using a test-driven approach. You can develop and test every major part of a system in isolation. Very cool. Over the years, I have developed many different types of software systems using EBAs. People sometimes find it perplexing that the salient classes in an EBA have no associations between them, but this is often a good thing because EBAs reduce coupling in order to reduce complexity. I have found that signal wiring diagrams are a good way to document and model EBAs. Although they are different from most of the diagrams you're probably seen before, they are easy to understand and easy to create.

http://www.ddj.com/architect/208801141

tamie message