From OpenNMS

Definitive OpenNMS

We're not looking for full blown UML [use cases] here, but we'll take what we can get. If you have some thoughts about the behavior of components in OpenNMS, please contribute them here.

Configuration

Good use cases for OpenNMS' configuration elements and behavior require continuous review and contribution from the community. Configuration elements (objects) and their attributes (properties) are a key aspect of the OpenNMS domain model and, when analyzed and designed correctly, writing OpenNMS code becomes much easier. (Writing code is much easier when following good design criteria).

Persistence

OpenNMS's use of Castor to allow the Configuration Object Model to be defined with XML and quickly converted to simple Java Objects, allows for great flexibility, easy programming, and is one of the most useful aspects to configuring OpenNMS. However, since OpenNMS has grown to be truly an enterprise class application, the behavior of the configuration, with respect to persistence, needs to be improved. The days of changing a configuration file by hand and restarting OpenNMS need to be put laid down to rest with the release of 2.0.

Contribute to this use case: Configuration Persistence

Packages

Many of the OpenNMS daemon services have defined a "package" element with its configuration serving as a container for definition attributes specific to the it's behavior. This container of configuration allows the user to organize many of the daemon's behavioral attributes and apply it to a set of entities (nodes, interfaces, services) with a rule. While this design is a very enterprise friendly aspect to configuration, it needs re-factoring to simplify configuration and reduce duplication.

Contribute to this use case: Configuration Packages

Acknowledgments in OpenNMS

Due to the fact that Alarms have only been recently introduced, the act of acknowledging an Event still exsists, and it should not, and acknowledging Alarms has no behavior other that a visual clue. However, acknowledging a notification has signficant impact on the notification process but this impact is isolated to the notification system.

An acknowledgment use case needs to be defined that the OGP can work from to improve this functionality in OpenNMS.

Alarms in OpenNMS

This is related to the acknowledgement use case but further defines the behavior of alarms with respect to correlation, automations, notifications, outage calendars, etc.

Event Translator

The Event Translator (ET) in OpenNMS is a flexible and powerful tool used that can be used to transform an event generated by one of the OpenNMS daemons into another event. This new event can be enriched with data using regular expressions against fields and parameters of the event itself as well as the result of an SQL query that better serves the network manager's business processes.

The ET has become quite popular and it is anticipated that it will become even more so with the release of 1.3.2. Already the community is beginning to seek enhancements to the functionality of ET and it is time to begin documenting the use cases for this feature in preparation for any further development and acceptance by the community. Please follow the Wiki link and contribute to this process. --David 09:51, 29 October 2006 (EST)