NUnit - Simple attribute based Unit Testing in .NET

NUnit is a open-source unit-testing framework for all .Net languages.

NUnit has two different ways to run your tests :-

• The console runner, nunit-console.exe, is the fastest to launch, but is not interactive.
• The gui runner, nunit-gui.exe, is a Windows Forms application that allows you to work selectively with your tests and provides graphical feedback.

Sample:-

Here's the way to write a test for a class (Account) - AccountTest. The first method test is TransferFunds.

namespace bank

{

   using NUnit.Framework;



   [TestFixture]

   public class AccountTest

   {

      [Test]

      public void TransferFunds()

      {

          Account source = new Account();

          source.Deposit(200.00F);

          Account destination = new Account();

          destination.Deposit(150.00F);



          source.TransferFunds(destination, 100.00F);

          Assert.AreEqual(250.00F, destination.Balance);

          Assert.AreEqual(100.00F, source.Balance);

      }

   }

 }

The first thing to notice about this class is that it has a [TestFixture] attribute associated with it – this is the way to indicate that the class contains test code (this attribute can be inherited). The class has to be public and there are no restrictions on its superclass. The class also has to have a default constructor.

The only method in the class – TransferFunds, has a [Test] attribute associated with it – this is an indication that it is a test method. Test methods have to return void and take no parameters. The Assert class defines a collection of methods used to check the post-conditions.

Compile and run this example. Assume that you have compiled your test code into a bank.dll. Start the NUnit Gui (the installer will have created a shortcut on your desktop and in the “Program Files” folder), after the GUI starts, select the File->Open menu item, navigate to the location of your bank.dll and select it in the “Open” dialog box. When the bank.dll is loaded you will see a test tree structure in the left panel and a collection of status panels on the right. Click the Run button, the status bar and the TransferFunds node in the test tree turn red – our test has failed.

There are other useful attributes like [Setup], [ExpectedException(typeof(InvalidOperationException))], and [Ignore("Ignore a fixture")]

More Reading on .NET code testing with NUnit at http://www.nunit.org/getStarted.html

Thanks to the authors for the above material from SourceForge/NUnit.

CCOW

"CCOW - Clinical Context Object Workgroup - is a vendor independent standard developed by the HL7 organization to allow clinical applications to share information at the point of care. CCOW enables the visual integration of disparate healthcare applications. "

Basically a "context management", software integration application. Specifically, CCOW defines a protocol for securely linking applications so that they tune to the same context. CCOW works for both client-server and web-based applications.

This means that when a clinician signs onto one application within a CCOW environment, and selects a patient, that same sign-on is simultaneously executed on all other applications within the same environment, and the same patient is selected in all the applications, saving clinician time and improving efficiency.

BUSINESS BENEFITS?

• Greater flexibility of choice for health providers when purchasing healthcare applications because CCOW offers widespread interoperability between software from different vendors
• Rapid, unified access for clinicians to patient data when they need it
  CCOW's single sign-on management capabilities improve user efficiency (fewer time-consuming sign-ons to applications)
• Context oriented workflow - clinical users can find and compare patient information they need quickly and easily, supporting better clinical decision-making
• Leverages existing investment - By CCOW-enabling existing IT resources, health providers can realize the benefits of a single sign-on, patient centric information system without major re-investment in new technologies.

CCOW specifies that a Context Manager component is responsible for maintaining the context. Applications are Context Participants that synchronize by querying the context manager to determine the current context and when they wish to update the context. CCOW also supports Mapping Agents, which map equivalent identifiers when the context is updated so that applications can interoperate without sharing the same identification information for patients or users.

CCOW provides two options for communication between components - a Web (HTTP) mapping, and an ActiveX mapping. This allows interoperation to occur even between applications employing different technologies.

I'd like to thank authors of the HL7 web site and other web sites involved with CCOW, for the above material.

WMI and SNMP

Microsoft Windows Management Instrumentation (WMI) technology support for Simple Network Management Protocol (SNMP).

• WMI is used to represent management objects in Windows-based management environments.
• The WMI scripting interface also provides scripting support.

The WMI technology also provides:

• Access to monitor, command, and control any managed object through a common, unifying set of interfaces, regardless of the underlying instrumentation mechanism. WMI is an access mechanism.
• A consistent model of Windows 2000 operating system operation, configuration, and status.
• A COM Application Programming Interface (API) that supplies a single point of access for all management information.
• Interoperability with other Windows 2000 management services. This approach can simplify the process of creating integrated, well-architected management solutions.
• A flexible, extensible architecture. Developers can extend the information model to cover new devices, applications, and so on, by writing code modules called WMI providers, described later in this document.
• Extensions to the Windows Driver Model (WDM) to capture instrumentation data and events from device drivers and kernel-side components.
• A powerful event architecture. This allows management information changes to be identified, aggregated, compared, and associated with other management information. These changes can also be forwarded to local or remote management applications.
• A rich query language that enables detailed queries of the information model.
• A scriptable API which developers can use to create management applications. The scripting API supports several languages, including Microsoft Visual Basic; Visual Basic for Applications (VBA); Visual Basic, Scripting Edition (VBScript); Microsoft JScript development software. Besides VBScript and JScript, developers can use any scripting language implementation that supports Microsoft ActiveX scripting technologies with this API (for example, a Perl scripting engine). Additionally, you can use the Windows Script Host or Microsoft Internet Explorer to write scripts using this interface. Windows Script Host, like Internet Explorer, serves as a controller engine of ActiveX scripting engines. Windows Script Host supports scripts written in VBScript, and JScript

The WMI technology architecture consists of the following:

• A management infrastructure. This includes the CIM Object Manager, which provides applications with uniform access to management data and a central storage area for management data called the CIM Object Manager repository.
• WMI Providers. These function as intermediaries between the CIM Object Manager and managed objects. Using the WMI APIs, providers supply the CIM Object Manager with data from managed objects, handle requests on behalf of management applications, and generate event notifications.

WMI ships with built-in providers (or standard providers) that supply data from sources such as the system registry. The built-in providers include:

• Active Directory Provider: Acts as a gateway to all the information stored in the Active Directory service. Allows information from both WMI and Active Directory to be accessed using a single API.
• Windows Installer Provider: Allows complete control of Windows Installer and installation of software through WMI. Also supplies information about any application installed with Windows Installer.
• Performance Counter Provider: Exposes the raw performance counter information used to compute the performance values shown in the System Monitor tool. Any performance counters installed on a system will automatically be visible through this provider. Supported by Windows 2000.
• Registry Provider: Allows Registry keys to be created, read, and written. WMI events can be generated when specified Registry keys are modified
• SNMP Provider: Acts as a gateway to systems and devices that use the Simple Network Management Protocol (SNMP) for management. SNMP MIB object variables can be read and written. SNMP traps can be automatically mapped to WMI events. SNMP provider snmpincl.dll root\snmp Provides access to SNMP MIB data and traps from SNMP-managed devices.
• Event Log Provider: Provides access to data and event notifications from the Windows 2000 Event Log.
• Win32 Provider: Provides information about the operating system, computer system, peripheral devices, file systems and security information.
• WDM Provider: Supplies low level Windows Driver Model driver information for user input devices, storage devices, network interfaces, and communications ports.
• View Provider: Allows new aggregated classes to be built up from existing classes. Source classes can be filtered for only the information of interest, information from multiple classes can be combined into a single class and data from multiple machines can be aggregated into a single view.

Simple Network Management Protocol (SNMP) is a network management standard that defines a strategy for managing TCP/IP and, more recently, Internet Packet Exchange (IPX) networks.

SNMP uses a distributed architecture that includes:

• Multiple managed nodes, each with an SNMP entity called an agent which provides remote access to management instrumentation.
• At least one SNMP entity referred to as a manager which runs management applications to monitor and control managed elements. Managed elements are devices such as hosts, routers, and so on; they are monitored and controlled by accessing their management information.
• A management protocol, SNMP, is used to convey management information between the management stations and agents. Management information refers to a collection of managed objects that reside in a virtual information store called a Management Information Base (MIB). A MIB thus contains the information requested by the management system.
• To communicate host information, management systems and agents use SNMP messages. These messages are sent using the User Datagram Protocol (UDP) and are routed between the management system and host by using the Internet Protocol (IP).

Processing Information Requests

• When a management system requests information, the following sequence occurs:
• A management system sends a request to an agent using the agent's IP or IPX address.
• The agent forms an SNMP datagram that contains an SNMP message and the community name to which the management system belongs.
• The SNMP agent receives the datagram and confirms the community name. If the community name is valid, the SNMP agent retrieves the appropriate data. Otherwise, if the community name is invalid, the request is rejected. If the agent has been configured to send an authentication trap, a trap message is sent.
• The SNMP datagram is returned to the management system with the requested information.

SNMP Messages

The following SNMP message types are used:

• Get This is a request message. SNMP management systems use Get messages to request information about a MIB entry on an SNMP agent.
• Get-Next A type of request message that can be used to browse an entire tree of managed objects.
• GetBulk A type of request that specifies that the agent transfer as much data as possible, within the limits of message size.
• Set This is used to send and assign an updated MIB value to an agent.
• Notification (or Trap) This is an unsolicited message that an agent sends to a SNMP management system when it detects a certain type of event has occurred locally on the managed host. Traps do not required acknowledgements.
• Inform SNMP Managers can communicate with each other using Inform Requests that require acknowledgements.

WMI SDK support for SNMP

• The SNMP Provider includes the following components:
  Class, instance, and event Providers that integrate the SNMP information modeling and processing into WMI. These SNMP providers map collections of object values to property values of CIM class instances.
• An SNMP information module compiler that compiles native SNMP schema information into the format that CIM uses.

Mapping Device Data to CIM Classes
The SNMP Providers map device data to CIM classes through the following methods::

• Enumerating SNMP Class Definitions. To enumerate a set of class definitions, applications can call IWbemServices::CreateClassEnum or IWbemServices::CreateClassEnumAsync.
  MIB objects are mapped to SNMP CIM classes using the OBJECT-TYPE macro; events are mapped to classes using the TRAP-TYPE and NOTIFICATION-TYPE macros.
  The OBJECT-TYPE macro is used to describe the basic characteristics of a MIB object. The SNMPv1 TRAP-TYPE and SNMPv2C NOTIFICATION-TYPE macros describe the characteristics of an SNMP event.
• Instantiating SNMP Class Definitions. To instantiate a class definition, applications can call IWbemServices::GetObject or IWbemServices::GetObjectAsync.
• Enumerating SNMP Class Instances. The SNMP instance Provider services requests to enumerate instances associated with classes that represent device MIBs.
• Instantiating SNMP Class Instances. The SNMP instance Provider processes requests to instantiate instances of classes that represent MIB objects.
• Retrieving SNMP Class Instances. To retrieve a particular instance of a SNMP CIM class, applications can call IWbemServices::GetObject or IWbemServices::GetObjectAsync.

SNMP and the CIM Schema
The schema that SNMP uses to define objects differs from that used in the WMI Common Information Model. The SNMPv1 and SNMPv2 schema is called the Structure of Management Information (SMI); it is packaged as MIB files. To define objects, the MIB files use Abstract Syntax Notation 1 (ASN.1), a standard language, and macro definitions that are used as templates for describing the objects. These macros supply information about the object, including its name, identifier, syntax, description, access rights, and so on.

This summary and below examples have been gathered from various sites including MSDN(Microsoft), needless to say I thank the authors for this public information.

Sample Code

• Read from an SNMP device. The following Visual Basic script example performs a Get operation on a device class.

Set objLocator = CreateObject("wbemscripting.swbemlocator")

Set objServices = objLocator.ConnectServer(, "root\snmp\mngd_hub")

objServices.security_.privileges.AddAsString("SeSecurityPrivilege")

Set objSet = objServices.ExecQuery _

("SELECT * FROM SNMP_NET_DEVICE_123 WHERE hdwr_idx>1",, _

wbemFlagReturnWhenComplete)

for each obj in objset

'do whatever

next

• Write to an SNMP device. The following script example performs a Set operation on a device class.

Set objLocator = CreateObject("wbemscripting.swbemlocator")

Set objServices = objLocator.ConnectServer(, "root\snmp\mngd_hub")

objServices.security_.privileges.AddAsString("SeSecurityPrivilege")

Set obj= objServices.Get("SNMP_NET_DEVICE_123=@")

obj.deviceLocation = "40/5073"

obj.put_

DataSets -- Performance Optimization with Remoting

http://msdn.microsoft.com/msdnmag/issues/04/10/CuttingEdge/default.aspx

What is DICOM and Why DICOM

      DICOM is Digital Imaging and Communications in Medicine and is a standard mainly used to distribute and view medical image files such as X-Rays, CT scans, MRIs, and ultrasound images.
      We are all used to the XRay film sheets we get from a hospital when we go in for a scan. Very cumbesome, difficult to archive, there are hospitals with librarians just to catalog and maintain these films for insurance and medical standards compliance purposes.
Now as we move to a digital world, we have softwares capable of viewing these images online and doctors remotely viewing/annotating these images (as reference material) and patients carrying home a/some digital picture(s)/movie(s) of the scan they had for insurance purposes, etc. All this is possible by the universal DICOM standard.
      Many companies have their own custom additions to the DICOM standards so two DICOM files from two vendors need not have the same contents even if they were from the same patient and output from the same medical device with the same resolution, settings etc. This is also part of DICOM flexibility, that private attributes may be added to facilitate a vendors custom needs to enhance the customer experience with the vendors software, etc.
      I leave you with lots of links to DICOM standards docs, some freeware to process these DICOM image files, and of course sample DICOM Image links, needless to say, thanking the authors for their public sites.


DICOM introduction and free software


Medical Imaging: Samples