Everyone and their mom knows that to make money, you have to start your own company.

Start company

…. (Do something ?)

Make money $$$$$

But what exactly is it, that one has to do to get the money coming in ?

How do you go about Designing ?

Designing code is somewhat similar. Everyone has read about Dependency inversion, has-a vs is-a, inheritance, polymorphism et all. But how does this lead to good classes ? You cant spell out “virtual” “polymorphism” into the compiler and hope that it produces those hip classes everyone drools about.

Our experience in creating a data collection framework for the base NMS (Network Management System) system that we were making, somewhat mimicked this conundrum. In this series i shall try to expound on how the classes got designed and how it ended up the way it ended up and how the design principles came useful.

Know Thy Requirement

Do you know your requirement

Before we grab a paper and start designing, let’s state the obvious. Unless you are a post modernist artist or someone equivalent, you cannot absolutely begin to create without knowing what your final output is going to be. After all quality, as defined by IEEE is

(1) The degree to which a system, component, or process meets specified requirements.
(2) The degree to which a system, component, or process meets customer or user needs or expectations.

No matter how many virtual functions you use, unless the software works, the number of levels of inheritance is going to mean zilch to the customer. So lets define what the users, in this case programmers who will use this library will expect out of it –

Our Requirement

When you want to create an NMS system, the core functionality can be generalized into collecting some data about the devices in the network, storing the same and updating (polling) it over and over again.

The data sources would differ, coming from SNMP, telnet, SOAP, WMI etc, depending on how the devices chose to expose their configuration. The value adds of the NMS like  alerting and presentation and such, are built on top of this basic inventory system. A scalable fast inventory system, to which it is easy to add new devices you want to support, is what you require as a basis for a good NMS system.

For our NMS system therefore, these become our requirements –

1.  Multiple Data sources has to be supported

2. All that should be required for collecting data, should be a specification of the data required ie meta-data. Once this is available the framework should be able to collect this data for you.

3. Programmers have to be able to EASILY work with the data thus collected before it is saved / thrown away.

4. Things have to be fast and small.

Know thy Constraints

Contraints are liberating aka drive innovation

Contraints are liberating aka drive innovation

It would be cool to have a scripting language available which can be used to work with the data we have collected and offer additional services from that platform, like saving, alerting, correlating etc.

However having a script engine running every time you collect the data is above the hardware support available to us. Additionally the time required to implement the scripting engine would be definitely more than the 2 man months available for coding this system, which brings us to the resource requirements / constraints

1. The product should run on small CPU system  (max dual core)

2. Only one person coding for 2 months will be available to finish this work.

Given the above constraints, a more viable solution would be to rather implement the whole system  as a small, efficient C++ module and make this data available in some manner to a scripting sub-system at some point in the life cycle. But this task would be of a lower priority due to resource constraints.

Scripting Hack

innovate

innovate

The desire for a suitable data description language and the lack of resources to fully implement one, along with the data requirements laid out, led us to make a system level design choice which is that

All attributes shall be made available to a Db stored procedure, inside which data manipulation level scripting can be achieved.

The additional advantages we had from this decision was that

  1. Using a stored procedure avoids descriptive and error prone C++ coding in all areas that require DB access
  2. Porting to another SQL data source is as easy as porting the SQL present in one file to the different system.
  3. Stored procedures would be MUCH more efficient than using anything else to talk to a database.

Real Systems are a product of Real Constraints

The way in which the external resource requirements and constraints play out in influencing the design decisions is probably new to novices. But this is a given fact in much of the designs that happen in real life scenario.

At times, this makes one adopt less than ideal decisions. However meeting those external criteria can be more important than achieving a buzzword-compliant system. Experience and depth of knowledge would help you here in making the best compromises.

In hind sight the decision to not develop a new scripting language and to use stored procedures as our data description language turned out to be a smart decision as it enabled us to churn out code much faster than any one else.

However a knowledge about databases and stored procedures and named parameters would have been essential to reach this decision. On the other hand knowledge of any rapid language development platforms might have led to a better solution, which perhaps a better code warrior might have been able to create.

Morale of the story ?

More extensive knowledge = Better design decisions.

So read all those blogs, try out new things and plug in to all those podcasts guys. Thats the only way to get better.

In the next installment of this series lets inspect how the actual class development progressed.

Advertisements