﻿Design architecture and implementation of development environment for ATML (Automated Test Mark-Up Language).
________________


Introduction
“For many years, the ATE (Automatic Test Equipment) industry has coveted a universal data exchange adapter for ATE, spurred by the need to share test system and test result information with the rest of the enterprise. Many test organizations within the ATE industry have already developed or are considering developing their own proprietary XML-based data exchange standards to meet their specific needs for sharing ATE and test information. However, this may no longer be necessary with ATML.”[1] 
This whole work describes my work as a test software engineer on the “ATML Tools” product being developed by Honeywell company. Due to this fact, the application’s source codes can not be publicly available and the appendices contain either only parts of the actual source codes or examples made by myself specifically for this bachelor thesis and screen shots of the actual application.
The first chapter of this thesis analyzes the problem and introduces the Automatic Test markup Language ATML technology.
The second chapter provides an overview of tools usable for automatic source code generation from XML Schema files and justifies our choice of the specific tool.
The third thesis chapter describes a software architecture of an ATML Tools and shows aspects and results of graphical user interface design.
Fourth chapter collects requirements and guidelines for graphical user interface of the ATML Tools and delivers sample screen shots from the actual application.
Chapter 1. The general problem analysis
For the automatic tests it is essential to be able to configure the tests and store the results in a format which should be both easily processed by computers and configurable by a human without  spending a big effort. The XML (Extensible Markup Language) satisfies both conditions. 
XML
XML belongs to a group of markup languages. People started using markup languages a few centuries ago. They were used at traditional publications and marking up manuscripts by adding instructions for a printer in the margins of manuscripts. He used these markups to know which font was about to be used and then passed the manuscript for typesetting. As a “father” of the modern markup languages is considered to be Charles Goldfarb, an IBM researcher, who transformed the idea into a fully functional product. Nowadays, the XML has widely spread to make a data exchange easier in the field of information technologies. This meta markup language describes rules how to define your own set of markups and ability to interpret them clearly in the future. Number of tools for parsing and processing XML files have been developed over many years. However, the XML is only a meta-language, so the set of elements used for describing the tests can vary not only from company to company, but also inside one corporation. That is why the IEEE Standard Association (IEEE-SA) developed the international standard IEEE Std 1671™ which was published as “IEEE Standard for Automatic Test Markup Language (ATML) for exchanging Automatic Test Equipment and Test Information via XML”.


ATML
 “Automatic test markup language (ATML) is a collection of IEEE standards and associated extensible markup language (XML) schemas that allows automatic test system (ATS) and test information to be exchanged in a common format adhering to the XML standard.”[2]


Historical Background
“In 2002, an automatic test markup language (ATML) focus group was formed (outside any formal
standardization body) with a mission to “define a collection of XML [extensible markup language] schemas that allows ATE [automatic test equipment] and test information to be exchanged in a common format adhering to the XML standard.”
The scope of this effort was the standardization of test information, which would allow for test program (TP) and test asset interoperability, as well as unit under test (UUT) data (including results and diagnostics), to be interchanged between heterogeneous ATE systems.”[2]


ATML is an XML-based standard for ATE and test information data exchange. It supports describing of wide spread of technical data and from simple electrical signal description to complex test stations. It also enables to define behavior of individual components and information exchange in a uniform format independent on used platform and hardware.
        Because ATML uses the XML standard for describing ATE and test data, it takes advantage of recursion and extensibility, key technical benefits that give test systems greater flexibility in defining interfaces. By supporting recursion, element definitions describing test properties or tests can nest to create a more managed data exchange format.
The IEEE-1671 standard consists of 6 parts covering different sections. A brief overview of the ATML Standard is:
- 1671.1 covers test descriptions, i.e. the descriptions of UUTs (units under test) and the particular set of tests that have to be performed on them.
- 1671.2 covers instrument descriptions and specific instrument instances, i.e. descriptions of general and specific instruments, which will often become UUTs.
- 1671.3 covers general UUT descriptions and specific UUT instance descriptions.
- 1671.4 covers test configurations.
- 1671.5 covers test adapter descriptions.
- 1671.6 covers descriptions of test stations.
In a short way, the problem is to find an effective way how to create documents compliant with the very complex XSD schemas of the IEEE-1671 standard. 
The aim of the work itself is to provide a detailed design of software development tools which shall create XML files compliant with IEEE-1671 standard. It covers my work as a designer of the main architecture, the choice of the used transformation technologies between XSD schema files and C# classes and a part of the GUI design. The application development pays attention to design the ATML Tools modular, so that written code can be massively reused across the different versions of software for different IEEE-1671 standard versions, which are not compatible with each other. 
1.1  General problem solutions
Since the ATML standard is relatively new and most of it is still in the trial-use state there are not many solutions implementing the ATML in the test systems. According to Ron Taylor, one of the main impediments implementing ATML is “Lack of ATML tools commercially available – The lack of ATML development tools commercially available is an issue that is limiting the use of ATML. [...] In addition as new programs are beginning to require ATML, the demand for tools will increase and drive their development. Without ATML tools the instance files must be generated manually which is time consuming and error-prone.”[3] Therefore the Honeywell ETS (Engineering Test Services) team based in Brno, Slatina decided to implement the ATML standard into their test processes and use it in their CTS (Common Test Station) as the format of exchanging test results. Implementing the ATML in the CTS includes development of the ATML Tools software in the .NET 4.0 framework.
        1.2 Goals of the work
1. Process the final work on the topic Detailed design of development tools for ATML IEEE Std 1671 standard-compliant XML files.
2. Find out possible ways of automated conversion of complex XML structures (defined by XML schemas) into C#/.NET data structures or classes.
3. Collect and prepare common requirements and guidelines for ATML tools graphical user interface.
4. Implement a part of ATML development tools GUI.


2. Converting XML schema structures into C# classes
        This chapter will describe the technologies used for making us able to work with the structures and types defined in the ATML standard. The goal was to achieve this functionality in the simplest possible way with the minimal effort needed. I will describe a comparison of possible technologies and attach short examples of the generated source codes as well as examples of working with the generated source code.
2.1 Problem Analysis
Since the ATML standard is de facto set of XML schema definition (XSD) files containing a big amount of more or less complex structures and types there is the need of the conversion of these types to C# classes. These classes will represent each of the ATML XSD complex types or simple types. Instances of these classes will be edited in the desktop application and then serialized back to XML and saved on disc. 
2.2 Possible solutions
Few possibilities emerged during solving this problem:
1. Manual writing of objects
2. Automatic conversion using XML Schema Definition Tool (Xsd.exe)[1]
3. Automatic conversion using LINQ to XSD[2]
4. Automatic conversion using XSD2Code[3]
The tool for automatic generation of classes shall provide the following features:
1. tool shall be free for commercial use
2. generate simple, readable and understandable source code
3. the generated code should not need any manual adjustments (adding code for serializing and deserializing objects or for input - output operations)
4. the source code should contain comments generated from XSD annotations
5. generate types from imported schemas into separate files
6. the tool shall be maintained by an external provider
7. tool should be integrated into the Microsoft Visual Studio 2010, if possible
Examples demonstrating Load from file and Save to file operations are provided below for solutions b), c) and d). As a base XML schema for generating examples I have used the Instrument Description[4] schema.  The source code comments in the examples are omitted in the printed version and can be viewed in the appendix.
2.2.1 Manual writing of objects
Since the number of types and their complexity in the ATML standard is significant, the manual writing of the classes has been rejected immediately  and as the only option proved to be the automatic generation of the classes. The manual writing had not been considered as usable for the ATML Tools project purposes and it won’t be considered in the thesis or figures anymore.
2.2.2 XSD Schema Definition Tool (Xsd.exe)
The XSD Schema Definition Tool was the first tool considered to be used for the automatic code generation purposes. It is the part of the .NET framework since .NET 1.1 and it communicates with user via command line. This tool has been considered as the first possibility of generating the classes we needed, since it is it’s main purpose. The tool did it’s work, however it does not provide us the settings and the configuration possibilities necessary for our purposes - excluding imported types, generating source code comments and it’s overall configurability is not satisfactory. Moreover, considerable amount of code had to be added for every generated class to be able to perform basic operations like loading and saving into the XML files. Example of serialization, deserialization and load - save source code needed to be added:
        public static InstrumentDescription Deserialize(string xml)
        {
            System.Xml.Serialization.XmlSerializer serializer = new System.Xml.Serialization.XmlSerializer(typeof(InstrumentDescription));


            System.IO.StringReader stringReader = null;
            try
            {
                stringReader = new System.IO.StringReader(xml);
                return ((InstrumentDescription)(serializer.Deserialize(System.Xml.XmlReader.Create(stringReader))));
            }
            finally
            {
                if ((stringReader != null))
                {
                    stringReader.Dispose();
                }
            }
        }


        public static InstrumentDescription LoadFromFile(string fileName)
        {
            System.IO.FileStream file = null;
            System.IO.StreamReader sr = null;
            try
            {
                file = new System.IO.FileStream(fileName, FileMode.Open, FileAccess.Read);
                sr = new System.IO.StreamReader(file);
                string xmlString = sr.ReadToEnd();
                sr.Close();
                file.Close();
                return Deserialize(xmlString);
            }
            finally
            {
                if ((file != null))
                {
                    file.Dispose();
                }
                if ((sr != null))
                {
                    sr.Dispose();
                }
            }
        }


       public static string Serialize(InstrumentDescription instrumentToSerialize)
        {
            System.Xml.Serialization.XmlSerializer serializer = new System.Xml.Serialization.XmlSerializer(typeof(InstrumentDescription));
            System.IO.StreamReader streamReader = null;
            System.IO.MemoryStream memoryStream = null;
            try
            {
                memoryStream = new System.IO.MemoryStream();
                serializer.Serialize(memoryStream, instrumentToSerialize);
                memoryStream.Seek(0, System.IO.SeekOrigin.Begin);
                streamReader = new System.IO.StreamReader(memoryStream);
                return streamReader.ReadToEnd();
            }
            finally
            {
                if ((streamReader != null))
                {
                    streamReader.Dispose();
                }
                if ((memoryStream != null))
                {
                    memoryStream.Dispose();
                }
            }
        }


       
        public static void SaveToFile(InstrumentDescription instrument, string fileName)
        {
            System.IO.StreamWriter streamWriter = null;
            try
            {
                string xmlString = Serialize(instrument);
                System.IO.FileInfo xmlFile = new System.IO.FileInfo(fileName);
                streamWriter = xmlFile.CreateText();
                streamWriter.WriteLine(xmlString);
                streamWriter.Close();
            }
            finally
            {
                if ((streamWriter != null))
                {
                    streamWriter.Dispose();
                }
            }
        }


        public static void XSDexeLoadSaveDemo()
        {
            // Load Instrument Description from PXI.xml file
            InstrumentDescription instrument = LoadFromFile("PXI.xml");


            // Save Instrument Description to PXI.xml file
            SaveToFile(instrument, "PXI1417.xml");
        }


The Xsd.exe tool does not provide any options to generate code comments from XSD annotations, which is necessary since the ATML standard contains hundreds of types. 
After an additional research, this tool appeared to be used in the XSD2Code application, which will be described later.


        2.2.3 LINQ to XSD
The first application which was considered as the fully usable for our purpose was an application which contributes to the LINQ (Language Integrated Query) project, in particular, enhances the existing LINQ to XML technology. LINQ to XSD is released under the Microsoft Public License (Ms-PL), as the user interface uses the command line and in the newest version needs at least .NET framework  3.5. 
Compared to Xsd.exe, LINQ to XSD generates all methods needed for serialization and deserialization inside every generated class. The Load and Save to file source code is therefore very simple:
        static void LinqToXSDLoadSaveDemo()
       {
           // Load Instrument Description from PXI.xml
           InstrumentDescription instrument = InstrumentDescription.Load("PXI.xml");
           
           // Save instrument Description to PXI1447.xml
           instrument.Save("PXI1447.xml");
       }


Despite LINQ to XSD generates source code comments, it does suffer from the same issue as the Xsd.exe - it can not exclude types included from other schemas from generation and provides the lack of options, this tool became unusable.
Unfortunately, this project is not maintained[5] since the 2010 and because it suffers from some serious issues crucial for ATML Tools project, it was decided not be used for our purposes.
        2.2.4 XSD2Code
The last tool we worked with was the XSD2Code application, released under Microsoft Reciprocal License (Ms-RL). It is available both as a command line application and Visual Studio extension, where provides Graphical User Interface (GUI) for easier configuration (Fig. 1).The application wraps the code generated by the Xsd.exe tool mentioned above with code needed for serializing and deserializing each of generated types, saving and loading from file and makes the user able to choose the type of collections used inside. The available collections are: Array, List<T>, IList<T>, ObservableCollection<T> and defined types. XSD2Code also provides the user with an option to generate source code comments from XSD annotations.
The source code needed to load and save the InstrumentDescription object is similar to LINQ to XSD’s:


    static void Xsd2CodeLoadSaveDemo()
   {
       // Load InstrumentDescription from PXI.xml file
          InstrumentDescription instrument = InstrumentDescription.LoadFromFile("PXI.xml");

       // Save InstrumentDescription to PXI1442.xml
       instrument.SaveToFile("PXI1442.xml");
   }


Automatic updates of the classes after updating the XSD files in the Visual Studio project is a welcomed function as well, but rather unused in the ATML Tools.
The XSD2Code has an alive community of contributors and is continuously developed.
In general, the XSD2Code provided the best configuration options and fulfilled most of our requirements for our needs.

Fig. 1 - XSD2Code GUI, taken from the XSD2CODE application
        2.3 Conclusion
To abide Honeywell Quality Function Deployment (QFD) process requirements, the following decision matrix (Fig. 2) along with a table (Fig. 3) of few pros and cons has been used. The decision matrix is an easy to understand model. Each criterion has an importance ranking and a score in range of 0 to 10. Criterion score is computed by multiplying these two values. Total score is made by an addition of total criterion scores.

Fig. 2 - Automatic code generation QFD

Fig. 3 - Automatic code generation tools pros and cons
After the QFD decision matrix results along with the additional criteria (additional source code needed to work with generated classes) were considered the XSD2Code tool has been chosen as the proper tool for our purposes with the most pros and none of the negative features.
        2.4. Generating classes with XSD2Code
As the decision has been made, we started to generate the ATML types from the XSD schemas using the XSD2Code tool. After reading documentation and several trials to use the generated code, we used a following options:
1. Serialization Enabled - True
2. IncludeCloneMethod - True
3. GenerateXmlAttributes - True
4. EnableDataBindings - True
5. ExcludeIncludedTypes - True
6. Platform - .NET 4
7. CollectionBase - Array
8. EnableSummaryComment - True
9. Namespace - “IEEE1671_20xx.yyyyy” (according to ATML version and  generated type - e.g. IEEE1671_2011.TestStationInstance)
10. CustomUsings - every ATML type that includes types from Common.xsd[6] and HardwareCommon.xsd[7] has added include of IEEE1671_20xx.Common and IEEE1671_20xx.HardwareCommon generated separately.
The other options were set to default. After examining the generated source code, we found out it had a serious problem. If the XSD schema contains an attribute group and another attribute group which contains referenco to the first one, the generated type containing the extended attribute group does not contain the nested group’s attributes. Sample XSD source code taken from the actual Common.xsd and InstrumentDescription.xsd without annotations is provided for better understanding the problem:
<xs:attributeGroup name="ClassifiedAttributes">
<xs:attribute name="classified" type="xs:boolean" use="optional" />
<xs:attribute name="securityClassification" type="c:NonBlankString" use="optional" />
</xs:attributeGroup>


<xs:attributeGroup name="DocumentRootAttributes">
<xs:attribute name="uuid" type="c:Uuid" use="required" />
<xs:attributeGroup ref="c:ClassifiedAttributes"/>
        </xs:attributeGroup>


<xs:complexType name="InstrumentDescription">
        <xs:complexContent>
                <xs:extension base="hc:HardwareItemDescription">
                        <xs:sequence>
                        [...]
                        </xs:sequence>
                        <xs:attribute name="type" use="required">
                                <xs:simpleType>
                                        <xs:restriction base="xs:string">
                                                <xs:enumeration value="Instrument"/>
                                                <xs:enumeration value="Module"/>
                                                <xs:enumeration value="Option"/>
                                        </xs:restriction>
                                </xs:simpleType>
                        </xs:attribute>
                        <xs:attributeGroup ref="c:DocumentRootAttributes"/>
                </xs:extension>
        </xs:complexContent>
</xs:complexType>
From the source code provided it is obvious, that the InstrumentDescription object contains all attributes specified in the DocumentRootAttributes attribute group, which means also the attributes classified and securityClassification inherited from the ClassifiedAttributes attribute group. However, the generated InstrumentDescription object contained only the attributes specified directly in the InstrumentDescription complex type - a required attribute named type and the non-inherited attribute specified in the DocumentRootAttributes attribute group - a required attribute named uuid.
        2.4.1 Custom changes in XSD2Code tool
To solve the serious problem mentioned above, I had to download and modify the source code of the XSD2Code application and use it to generate classes for the ATML Tools. Since the XSD2Code source code is reasonably divided into several projects, I did not have hard time locating the file which needed to be edited.
The problem was in a Xsd2Code.Library.Generator class, inside the method internal static Result<CodeNamespace> Process (GeneratorParams generatorParams) namely the Get XmlTypeMapping region. The source code did not search attribute group references recursively but just looked for the first level references. I fixed it with replacing the whole Get XmlTypeMapping region with the following code:
#region Get XmlTypeMapping
string rootFolder = "";
if (generatorParams.InputFilePath.IndexOf("\\") > 1)
rootFolder = generatorParams.InputFilePath.Remove (generatorParams.InputFilePath.IndexOf("\\"));


XmlSchema rootSchema = XmlSchema.Read(XmlReader.Create( generatorParams.InputFilePath), new ValidationEventHandler(Validate));
var schemaSet = new List<XmlSchemaExternal>();


ExtractIncludes(rootFolder, rootSchema, ref schemaSet);
var schemas = new XmlSchemas { rootSchema };
schemaSet.ForEach(schemaExternal => schemas.Add(GetSchemaFromFile(rootFolder, schemaExternal.SchemaLocation)));


// Find and replace all nested attributeGroupRefs with their respective //attributeGroups
// Keep processing until there are no attributeGroupRefs left that are more //than one level deep
foreach (XmlSchema schema in schemas)
{
        bool replacementOccurred = true;
        while (replacementOccurred)
      {
           replacementOccurred = false;
           foreach (XmlSchemaAttributeGroup group in schema.Items. OfType<XmlSchemaAttributeGroup>())
           {
                // Get the list of all the attributeGroupRefs in this //attributeGroup
                List<XmlSchemaAttributeGroupRef> groupRefs = group. Attributes.OfType<XmlSchemaAttributeGroupRef>(). ToList<XmlSchemaAttributeGroupRef>();
                for (int i = groupRefs.Count - 1; i >= 0; i--)
                {
                    // Locate the referenced attributeGroup
                    // and add all of its attributes to the outer  //attributeGroup
                     XmlSchemaAttributeGroupRef groupRef = groupRefs[i];
                     XmlSchemaAttributeGroup refGroup = schema.Items. OfType<XmlSchemaAttributeGroup>().First(x => x.Name == groupRef.RefName.Name);
                     foreach (XmlSchemaObject att in refGroup.Attributes)
                                group.Attributes.Add(att);
                     // Remove the reference
                     group.Attributes.Remove(groupRef);
                     replacementOccurred = true;
}
}
}
}
schemas.Compile(null, true);


var importer = new XmlSchemaImporter(schemas);
var exporter = new XmlCodeExporter(ns);
var mappings = new List<XmlTypeMapping>();
foreach (XmlSchemaType schemaType in rootSchema.SchemaTypes.Values)
   mappings.Add(importer.ImportSchemaType(schemaType.QualifiedName));


foreach (XmlSchemaElement schemaElement in rootSchema.Elements.Values)
   mappings.Add(importer.ImportTypeMapping(schemaElement.QualifiedName));
            
mappings.ForEach(exporter.ExportTypeMapping);
#endregion
Whole XSD2Code with the fix is placed in the appendix on the CD.
3. ATML Tools modular architecture
The following chapter will discuss collecting and preparing common requirements for the ATML Tools software architecture and the Graphical User Interface (GUI).
3.1. Problem analysis
The ATML standard consists of 6 parts describing different sections necessary to implement into testing process. Since the standard is currently in the trial-use state, the patches and updates are released on regular basis. The basic requirement is that the ATML Tools software has to be able to support current version implemented in Honeywell company as well as all versions released in the future. Hence came out the need of highly modular software and also an appropriate GUI. 


Software applications in aerospace industry often last for 20 years and longer, therefore also the ATML Tools has to count with the ability to be extended with new ATML editors, or other editors which are somehow related to the testing industry - for instance the editor of the signal maps, or “TSF Creator” - a custom editor of the IEEE 1641 Test Signal Framework (TSF) library. 
Another requirement is that the customer shall be able to configure the ATML Tools to his specific needs - add or remove editors and plug-ins. To provide this ability, the application shall be able to work with plugins developed by Honeywell, or even by a third party company. Hence we need to decide what technology will be used to provide high modularity and design the system architecture as robust as possible.
Let us define important definitions first:
Extensibility is “a mechanism for manipulating host application objects or extending host functionality, sometimes referred to as automation. Generally made available via an object model published as part of a host's SDK.”[4]
Add-In (also called Add-On, Extension, Plug-In, Snap-In) is “a customization; an assembly loaded by a host. Also, something that automates a host application (such as a client). Something that provides additional functionality to a host (service). An add-in is custom code, usually written by a third party, that is dynamically loaded and activated, by a host application, based upon some context (such as host startup or document loading). The add-in extends the host application via the host's public Application programming interface (API) (for example, an object model or managed class library) which was made available to the add-in via an Software Development Kit (SDK).”[4]
3.2. Possible solutions
There are several frameworks providing support for exetensibility on the market. Of course only solutions working with .NET 4 and above have been considered as useable. 
Two technologies have been considered to be operable for the ATML Tools purposes:
1. Managed Add-In Framework (MAF)
2. Managed Extensibility Framework (MEF)
Detailed description of both of these frameworks is beyond the scope of this bachelor thesis, so I will provide just a brief overview of both technologies.
Note: Certain level of extensibility can be achieved using reflection. This approach is only possible in certain situations and can not be considered correct. Despite this, the decision matrix (Fig. 6) contains System.Reflection as one of possible solutions just to provide wider scope of possibilities.


Managed Add-In framework[8]
The MAF is a part of the .NET, introduced in the version 3.5. It’s types are placed in a System.AddIn namespace. It specializes itself to loading and unloading the add-ins, their sandboxing and isolation. MAF allows add-ins to run in their own application domain, so crashing of one of the add-ins does not have to mean the whole application crashes along.
“At the center of the MAF-based application is the pipeline. Communication between add-ins and the host application is strictly regulated by the pipeline. The pipeline is dynamically created by MAF through a set of loosely-coupled components which are used to version, marshal and transform the data as it passes back and forth between the host and each loaded add-in.



Figure 4 - MAF Pipeline. Taken from [6]


Each section of the pipeline is contained in a separate assembly, loaded as necessary to manage the specific add-in. MAF discovers each component and then loads them on request using reflection.
For reliability, MAF allows optional isolation boundaries to be created between the add-in and host – everything to the left of the contract is loaded into the main (host) AppDomain and everything to the right loaded into a newly created AppDomain which has its own security permission set. The isolation can also be done through cross-process calls if true process-level isolation is necessary. Under the covers, the system uses traditional remoting calls to do the work of marshalling calls back and forth.”[6]




Managed Extensibility Framework[9]
The MEF project started in 2008 and has been included in the Microsoft .NET 4.0. Velvark, Novak and Granitz in the “Visual Studio 2010 and .NET 4 Six-in-One” book describe MEF as follows: “MEF as a technology is intended to enable greater reuse of applications and components by turning today’s statically compiled applications into dynamically composed ones.”[5] The MEF types and attributes are declared in the System.ComponentModel.Composition namespace. It allows users to use extensions without any configuration required. Using MEF along with MAF is possible and the application can take advantages of both of them.
The application using MEF is composed out of parts. Part is an elementary building block of the MEF application. The parts specify their imports and exports. Imports can be objects or methods which you intend to use in your part. Exports are methods or objects that the part offers to be used by other parts. The parts are composed at runtime - the the imports are satisfied with the exports. The key feature for dynamic discovering available parts is the Catalog. There are several types of catalogs, most important are:
1. AssemblyCatalog - discovers parts in the given assembly
2. DirectoryCatalog - discovers parts in the specified directory
3. AggregateCatalog - can combine multiple catalogs
Obviously users can create their own implementation of catalogs (e.g. if there is a need to get the exports from a database, write your own  DatabaseCatalog).
Catalogs are at runtime given as input to CompositionContainer and it performs composition from discovered parts.
Very important feature of the MEF is a lazy instantiation. “[...] during composition of a part, an import will trigger the instantiation of a part (or parts) that expose the necessary exports required for the original requested part. In the case of imported properties and fields, this means that their values are set before they are used. In many situations, it may happen that the properties are not used at all, or are used later after their original construction. If the instantiation of property values is expensive (takes a relatively long time, consumes many CPU cycles, holds a large amount of resources, and so on), it is a good approach to delay this instantiation — and prevent the recursive composition down the graph.”[5] For this purpose MEF provides a new type of a generic container - Lazy<T>. The instances are now accessed through a Lazy<T>.Value property instead of direct access to an imported type. “The actual instantiation of the part is carried out when Value is fi rst queried, and subsequent queries use that cached instance.”[5]
3.4. Conclusion
Like when choosing the classes generator, modular architecture technologies choice followed the QFD process. The following pros and cons table and decision matrix has been produced:

Figure 5 - Modular Architecture Technologies pros and cons

Figure 6 - Modular Architecture QFD
3.4. Solution
The application is based on Windows Forms technology. It consists of the main application window which contains the main menu with items to create new or open ATML Files, options and with items for each available ATML editor. Therefore the AtmlToolsMainForm class serves as the main application form opened after the application start and it also serves as the host part of the MEF classes. Hence as the first method in constructor, the Compose method is called. The Compose method’s content is following:
private static string EDITORS_PATH = Path.GetDirectoryName(Application.ExecutablePath) + "\\Libraries\\Editors\\";


/// <summary>
/// Contains imported instances of IAtmlEditor and theirs metadata.
/// </summary>
[ImportMany]
public IEnumerable<Lazy<IAtmlEditor, IAtmlEditorData>> Editors 
{ 
get;
set;
}


public void Compose()
{
      AggregateCatalog catalog = new AggregateCatalog();
      catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly));
      catalog.Catalogs.Add(new DirectoryCatalog(EDITORS_PATH));
      container = new CompositionContainer(catalog);
      try
      {
              container.ComposeParts(this);
      }
      catch (CompositionException ex)
      {
          MessageBox.Show(ex.Message, "Composition Error!");
          throw;
      }
}


The AggregateCatalog is used to combine two catalogs - an AssemblyCatalog locating the parts in the current assembly and the DirectoryCatalog, which is discovering the parts in assemblies located in the directory specified by a relative path. After the composition is completed, the main menu is created so that every found editor plug-in has it’s own menu item and is shown in the project wizard. Whenever an assembly containing a plug-in is placed in the specific folder and the application is restarted, the new plug-in is ready to use.
3.5. Further improvements
The future versions of the ATML Tools will aim to the user comfort. Several enhancements are planned in the editors - the InstrumentDescription’s Networking section will have fully graphical interface. The ATML Tools will be extended with custom editors - “TSF Creator” and “Signal map editor” for a complex testing experience. Through using the MEF technology, it is enabled to accept third party editors. However there is still space to improve the genericity and make the application core more lightweight with less hard dependencies.


4. GUI design
One of the main objectives when designing the application is to create an appropriate graphical user interface. In this chapter I will give an overview of requirements and best practises of GUI design and their implementation when designing the "ATML Tools".
4.1. Problem analysis
The goal is to design GUI so that it will be:
1. useful
2. effective
3. as simple as possible
4. following the CRAP (contrast, repetition, alignment, proximity) principle
We have identified 10 types of users who interact with ATML Tools:
1. Administrator: has access to all ATML tools components and is able to change access rights and ATML tools components configuration.
2. Product Design Engineer: creates and maintains UUT description documentation.
3. Product Manufacturer: creates UUT instance file for each instance of UUT.
4. Test HW design Engineer: creates and maintains Test HW description data (Instruments, Test Adapters, Test Stations) and read UUT and Test SW data.
5. Test SW design Engineer: creates and maintains Test SW description data (Test Description, Signal libraries) and reads UUT and Test HW data.
6. Test Configuration Manager: creates and maintains Test configuration data and read all test system description data.
7. Test HW manufacturer: creates and maintains Test HW instance data (Instruments, Test Adapters, Test Stations).
8. Test System Domain Lead: inspects and analyzes all Test system description data.
9. ISC technician/ Maintenance: updates UUT instance file and analyzes archived reports.
10. AME / VE ISC Support: performs statistic analysis and data evaluation of archived reports and read test system environment data


4.2. Solution
Since 7 out of 10 identified users are users on engineering positions who are generally familiar with advanced engineering or development tools such as Microsoft Visual Studio or NI TestStand[10], we decided to design the ATML Tools so that it would look and behave similarly.
The first two goals was to make the user rearrange various editor windows and other tools such as a Project Explorer or a Properties window across the screen and to allow running application on multiple monitors, as the engineers often work with two and more screens simultaneously. To deliver these features, we used the DockPanel Suite.[11] The DockPanel Suite project declares itself as inspired by Microsoft Visual Studio and I have to confirm this statement. The DockPanel Suite is very easy to use - with minimum source code and configuration needed delivers full Visual Studio-like docking experience.
Placement of singular windows is by default set as follows:
1 - Editor window, 2 - Project Explorer, 3 - File Properties window, 4 - Main menu

User can undock any window and move it to another desktop, or dock it to any part of the application window.
(Budu pridane dalsie veci)
________________
5. Conclusion
The goal of the thesis was to find out possible solutions of automatic generating source code from the XML schema data structures and provide useable C# classes generated from the IEEE 1671 standard. Three of possible solutions have been compared. It was decided to use the XSD2Code tool, however I had to fix the bug in the XSD2Code. The functional has been solution is provided and used in the ATML Tools software.
Another of the main goals was to find the possibilities to make the application extensible and describe a high-level architecture and solution. I compared two frameworks that provide wanted functionality and are included in the .NET 4 framework - MEF and MAF and then described the solution where we used the MEF framework.
The last chapter was about designing the GUI of the application. Since the whole application can not be disclosed, the screenshots of the final design are in the appendix.
The ATLM Tools software was successfully released on 5th December 2012. According to a plan it will be incorporated in the Honeywell CTS Core and it will be used across the company to implement new generation of automatic tests. The software will significantly contribute to rapid test development and the test results exchange between Honeywell sites across the globe.
________________


Appendix A - ATML Tools GUI
(nasledujú screen shoty z aplikácie)
Bibliography
[1] ATML - The Standard for Interfacing Test System Components using XML. 2012. URL: http://www.ni.com/white-paper/3893/en#toc7
[2]        IEEE Computer Society. IEEE Standard for Automatic Test Markup Language (ATML) for Exchanging Automatic Test Equipment and Test Information via XML. 345 E. 47th St, New York, NY 10017, USA: IEEE Computer Society, 2011.
[3] TAYLOR, Ron. SUMMIT TEST SOLUTIONS, Fallbrook, CA, USA. Software tools: A key component in the successful implementation of the ATML standards. 2011. ISBN 978-1-4244-9362-3. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6058788&isnumber=6058721
[4] http://msdn.microsoft.com/en-us/magazine/cc163476.aspx
[5] Velvart, Andras; Novak, Istvan; Granicz, Adam. Visual Studio 2010 and .NET 4 Six-in-One.
Hoboken, NJ, USA: Wrox, 2010. p 463.
http://site.ebrary.com/lib/masaryk/Doc?id=10469798&ppg=505
[6] Smith, Mark. Creating extensible applications with MAF. 2008, URL: <http://www.developerfusion.com/article/9396/creating-extensible-applications-with-maf/>
________________
[1] http://msdn.microsoft.com/en-us/library/x6c1kb0s(v=vs.100).aspx
[2] http://linqtoxsd.codeplex.com/
[3] http://xsd2code.codeplex.com/
[4] InstrumentDescription.xsd, available from http://grouper.ieee.org/groups/scc20/ATML/Demonstrations/ Phase3/Baseline%20ATML%20Schemas/InstrumentDescription.xsd
[5] http://linqtoxsd.codeplex.com/discussions/81738
[6]http://grouper.ieee.org/groups/scc20/ATML/Demonstrations/Phase3/Baseline%20ATML%20Schemas/Common.xsd
[7]http://grouper.ieee.org/groups/scc20/ATML/Demonstrations/Phase3/Baseline%20ATML%20Schemas/HardwareCommon.xsd
[8] MAF Overview - http://msdn.microsoft.com/en-us/library/bb384200(v=vs.100).aspx
[9] MEF Overview - http://msdn.microsoft.com/en-us/library/dd460648(v=vs.100).aspx
[10] http://sine.ni.com/np/app/main/p/docid/nav-94/
[11] http://dockpanelsuite.com/