The monitor system

In a previous post I described the basic of the project I worked on and how I would implement it now. When starting a project it is good to write down what to expect from the software that is getting developed, this is something that was not really done for the previous version (at least not that I know of). Because I start the project all over again, I will start this new project by writing down that description.

The context

The broadcaster I worked for is using a complex computer network for distributing and broadcasting radio programs. The complete network is spread across the world and monitoring the whole network can hardly be done by hand and will be automated. (Well we did monitor the whole system by hand for some months because we just implemented the system before the software was ready, but that was not funny...)
On the network there are different kind of devices we have to monitor including: computers, modems (for connecting to the Internet) and UPS-es. All the devices on the network should be monitored (when possible) and it would be nice to keep a history of the state of the devices.
The computers are used for several things: first of all programs are played, but before that schedules should be checked as well as the integrity of the files and a lot of other things. All the programs keep a kind of log (of course) but it is useful to hold some of the information on a central place. There are also some OS things that should be monitored like disk-space and memory usage.
When there is something going wrong (all devices on a site are turned off, the play-out at a site is terminated, etc.) alarms should go off and a hot-line should be called, things should be corrected as soon as possible. (Ideally when computers are not accessible due to a network connection error, other programs in the system should be informed as well so they don't try to distribute file to those computers)
From the network side of the system, the network traffic that is generated by the system should be as small as possible, especially the traffic between locations. Although this can be solved during deployment of the system (run the application on each location) we still need to include support for this during design time.

The requirements

Here is a list of the requirements that comes to my mind. This list is not complete, but that is not a problem because I want the system to evolve over time.

• The state of device should be monitored
• The state of applications (play-out, OS, etc.) should be monitored
• Different kind of alarms should be generated
• States of devices and applications should be saved
• It should be possible to configure what and how to check on the network

• It should be easy to add new locations, devices and applications
• Visual monitoring should be easy and always up to date
• Monitoring is critical but less critical then the whole play-out process
• Network overhead should be as low as possible

These requirements can be split in two areas, architecture requirements and functional requirements. I will mainly focus on the functional requirements because these are the easiest to test automatically and will most likely contain business logic.

Project restrictions

This project is started for learning purposes and not to write a complete and fully functional application. I will use this project to learn (and explain) the following things:

• Object Oriented programming
• C# (.NET and Mono)
• Multi platform development (Linux and Windows)
• Domain Driven Design
• Test Driven Development
  
• Perhaps some Service Oriented Architecture (if I see it fit)
• Object Relational Mappers for persistence
• Agile/Iterative project management
• (Design) Patterns
  
• and probably some other techniques that come on my path
  

Well that's all for today, next time I will talk a bit about Domain Driven Development and/or Test Driven Development. (which can go hand in hand :))