Министерство на електронното управление

За реализацията на подхода за универсално описание на информационни обекти е използван MS Excel, като може да бъдат използвани и други продукти, работещи с таблични данни.
Настоящият подход за универсално описание на информационни обекти е аналогичен на UML Class диаграмите. За представянето на UML Class се използва множество от таблици, организирани като страници в един файл, вместо обичайното графично рисуване и използва само избрана част от елементи от UML Class, с цел опростяване (няма необходимост от експертни знания) и еднозначност.
Табличното представяне е човешки четимо и обхваща широка целева група – от бизнес потребители до програмисти. Това е така, защото почти всеки човек с компютърна грамотност разбира от таблично представяне на данни и може да разбере описанието на информационните обекти. Въпреки че графичното представяне е по-изразително, то има необходимост от познаване на изразните му средства (експертно знание).
Табличното представяне може да бъде машинно четимо, в случай, че се запише в подходящ формат файл (например XLSX) и всяка смислова единици може еднозначно да се отдели от останалите (т.е. всяка стойност да бъде в отделна клетка). Автоматизирането на прехвърлянето на данни от голям обектен модел би изключило напълно грешки и забавяне, каквито биха били предизвикани в случай на изпълнение на тази задача от човек. Повечето среди за създаване на диаграми предлагат възможности за извличане на данни, което е по-специфично експертно знание, спрямо четенето на XLSX файл.
В настоящия подход има два типа връзки: 
•    логически връзки с полета към тях; 
•    йерархични връзки. 
Изразителната сила на връзките в подхода е идентична с тази на UML Class диаграмите. Създадени са различни видове връзки, за да може един символ да даде възможно най-много информация, без значение от използваното графично представяне, особено при най-често използваните елементи.
В UML Class диаграмите се използват поне две разновидности на йерархични връзки – Inheritance (или Generalization) и Realization. В настоящия подход ще се ползва еквивалентът на Inheritance. Най-общо, ако информационен обект X наследява информационен обект Y, то обект X получава всички полета на обект Y. Понеже не се допускат две полета с едно и също име в един обект, то добавянето на йерархична връзка може да доведе до грешки. 
В UML Class диаграмите се използват поне пет разновидности на логически връзки – Association (общ тип), Directed Association, Reflexive Association, Multiplicity, Aggregation и Composition. В настоящия подход ще се използва еквивалентът на Association. Разпознаването на останалите връзки, от експерт, в настоящия подход става чрез анализ на контекста и би могло да се автоматизира.
Една логическа връзка с име L между два информационни обекта X и Y и етикети X-Label и Y-Label в табличен вид може да се представи посредством:
•    добавянето на нов информационен обект с име L и две задължителни полета с типове съответно X и Y, където имената на полета са етикетите на връзката. 
o    Ако всяко от полетата е уникално, то връзката X/Y е едно-към-едно. 
o    Ако само комбинацията от полетата е уникална, то връзката X/Y е много-към-много. 
o    Ако комбинацията от полетата е уникална, X полето е уникално и Y не е уникално, то връзката X/Y е едно-към-много, а връзката Y/X е много-към-едно.
•    добавянето на задължителни полета X-Label от тип Y (или колекция от Y) в обект X и Y-Label от тип X (или колекция от X) в обект Y.
o    Ако и двете полета са от тип единичен обект, то връзката е едно-към-едно.
o    Ако и двете полета са от тип колекция, то връзката е много-към-много.
o    Ако поле X-Label в X е от тип колекция от Y, а другото Y-Label в Y от тип колекция от X, то връзката X/Y е много-към-едно, а връзката Y/X е едно-към-много.
Първият вариант е много подходящ за едно-към-едно и много-към-много връзки, защото дава възможност връзката да бъде между повече от два елемента и премахва неудобството на втория вариант – обяснение, че промяната на едно поле в един обект (единия край на връзката) автоматично ще промени друго поле в друг обект (другият край на връзката).
Втория вариант е много удобен за връзки от типа много-към-едно, като се има предвид, че полето от тип колекция се пропуска, защото се подразбира.