CC BY
29Разработка методик представления моделей информационно-измерительных систем испытательных стендов с помощью нотации UML
Андреев С.В. ( sergey.andreev@vitec.ru ) СПбГТУ 1. Введение
Промышленные испытательные стенды вертолетных редукторов (ИСВР) предназначены для проверки работоспособности изделий (вертолетных редукторов - ВР), эксплуатируемых в сложных условиях, неправильная работа которых в реальном режиме может привести к материальным убыткам, травмам обслуживающего персонала или даже гибели людей. ВР монтируется на стенде перед испытанием, в процессе которого на него подаются необходимые режимные усилия, и, тем самым, проверяется его работоспособность. Сложность ручного управления стендом приводит к необходимости его автоматизации с использованием ЭВМ всех видов - от микроконтроллеров до настольных и промышленных ПК. Огромная вычислительная мощь, большие ресурсы памяти, низкая стоимость и доступность ПК, широкий спектр прикладного и системного программного обеспечения (ПО) определяют необходимость использования ПК в современных ИИС ИСВР. Высокий уровень сложности ИИС ИСВР приводит к необходимости предварительного моделирования системы в целом - от создания физических моделей до создания моделей ПО.
В статье разрабатываются методики расширения и использования нотации UML [2] и UML Real Time [15] для моделирования и описания ИИС ИСВР. Выявляются недостатки и ограничения, которые накладывают эти нотации при их использовании в измерительной предметной области. Для адаптации нотаций к ИИС ИСВР используются стандартные механизмы расширения UML.
2. Выявление источников сложностей в ИИС испытательных стендов
Сложность таких больших систем как ИИС ИСВР, согласно [1] определяется четырьмя основными причинами:
• Сложностью реальной предметной области, из которой исходит заказ на разработку.
В ИИС это обусловлено работой в режиме реального времени и постоянным
взаимодействием с измерительной аппаратурой, в том числе необходимостью обрабатывать от нее потоки данных без потерь измерительной информации; высокой точностью и надежностью результатов измерений, большим объемом информации, который необходимо надежно сохранять (возможно, с использованием резервирования); оперативной модификацией устаревшей информации; многопотоковым управлением, прозрачным представлением распределенных систем, обеспечением работы с интерфейсом программы в интерактивном режиме и адекватным представлением всех сложных процессов, происходящих внутри ИИС во времени. Кроме того, каждой ИИС ИСВР присущи сложности, обусловленные ее предметной под-областью - это сложность методик испытания вертолетных редукторов, необходимость метрологической аттестации внутренних систем стенда, нетривиальные методики обработки получаемых со стенда сигналов и т. д.
• Трудностью управления процессом разработки.
В связи со сложностью, а иногда и непредсказуемостью управляемого объекта (ИСВР) часто возникает необходимость доработки ПО, а иногда и полной переделки отдельных его частей. Возникает проблема неточного планирования времени разработки
программы, что приводит к финансовым потерям как разработчика ПО, так и заказчика. Выходом может стать создание унифицированного процесса проектирования (УПП) ИИС ИСВР. Подобные процессы существуют на более высоких уровнях (например [2]) и могут послужить базой для создания более конкретного УПП для ИИС ИСВР.
• Необходимостью обеспечить достаточную гибкость ПО ИИС.
Гибкость ПО позволяет повысить уровень его повторного использования и поэтому сократить время на выполнение последующих заказов на разработку ПО ИСВР. Для создание гибких программных систем целесообразно использовать предварительное моделирование ПО, в частности, для создания модели каркаса (ядра) ПО ИСВР. Последняя задача является особо сложной в программировании, однако, ее решение дает самые лучшие и надежные результаты при дальнейшем использовании модели. Таким образом, для создания гибкого ПО от разработчика требуется глубокое знание не только программных сред разработки, но и методов анализа и проектирования ПО.
• Неудовлетворительными способами описания поведения больших систем.
Как правило, для описания больших систем требуется использовать несколько ее представлений (физическое, структурное, динамическое и др.). К сожалению, очень сложно найти такую нотацию для описания ИИС ИСВР, которая полностью отражала бы ее специфику.
3. Анализ нотаций, применимых для моделирования и описания ИИС испытательных
стендов
При создании различных моделей ИИС ИСВР встают задачи исследования методов представления систем и анализа применимости этих методов в рассматриваемой предметной области. Рассмотрим различные объектные нотации, которые могли бы быть использованы для представления ИИС. Наиболее популярные из них в настоящее время - это UML [2] (и ее расширение UML Real-Time [15]), OMT, нотации Буча [1], Рамбо, Джекобсона, Румбаха, Коада и Йордана, Константайна [2] и др.
Как правило, все эти нотации рассматривают взаимодействие элементов системы в двух измерениях: логическом/физическом и статическом/динамическом [1]. В каждом из двух измерений строится несколько диаграмм, которые дают нам вид системы в различных ракурсах. Таким образом, модели системы содержат всю информацию об ее классах, связях, физическом представлении и других сущностях, а каждая диаграмма представляет одну из проекций системы [1].
К середине 90-х годов Грейди Буч, Айвар Джекобсон и Джеймс Рамбо предприняли попытку объединить свои методы. Их попытка увенчалась успехом и был создан унифицированный язык моделирования UML (Unified Modeling Language) [2], который теперь является стандартным средством для визуализации, спецификации, конструирования и документирования программного обеспечения (ПО). При рассмотрении статических частей системы в UML используются следующие четыре типа диаграмм: классов, объектов, компонентов и развертывания, которые все вместе называются структурными диаграммами: y/CL(C,I,K,Rclk) - диаграмма классов, включающая множество классов С, множество
CIK
интерфейсов I, множество коопераций K и отношения между ними R .
WDBj(V,Rv,to) - диаграмма объектов, включающая множество объектов и отношения на нём Rv в данный момент времени t0.
Wc0MP(S,Rs) - диаграмма компонентов, включающая множество компонентов S и отношения на нём Rs.
SD
Wdepl(D,S,R ) - диаграмма развертывания, включающая множество узлов D, множество компонентов S и отношение между ними RSD.
Для работы с динамическими частями системы применяются пять типов диаграмм: прецедентов, последовательности, кооперации, состояний и деятельности, которые называются также диаграммами поведения:
Wuse(U,A,Ru) - диаграмма прецедентов, включающая множество прецедентов U, множество актеров A и отношения между ними RAU.
Щseq(V,M,Rv,Ai) - диаграмма последовательности, включающая множество объектов V, множество сообщений M и отношения между объектами R в течении времени At. Внимание акцентируется на временной упорядоченности событий.
Щсоь(У,МЖ) - диаграмма кооперации, включающая множество объектов V, множество сообщений M и отношения между объектами R. В отличие от предыдущей диаграммы акцент делается на структурной организации объектов, принимающих и отправляющих сообщения.
щиUN(F,TF,At) - диаграмма деятельности, включающая множество деятельностей F, и оператор переходов T, управляющий потоком переходов от одной деятельности к другой в течении времени At.
V/SM(G(U,V),TSM,At) - диаграмма состояний, включающая граф переходов G(U,V) и множество правил TM, определяющих переходы из одного состояния в другое в течении времени At.
Одним из достоинств UML является встроенные в него механизмы расширения существующих элементов нотации для использования в более узких областях знаний. В число механизмов расширения входят стереотипы, помеченные значения и ограничения. Кроме того, спецификация позволяет создавать свои элементы для более удобного представления программы. Благодаря этим возможностям, для создания модели ИИС ИСВР, удобным является использование следующих диаграмм:
• Для представления физической модели ИСВР (измерительной аппаратуры и агрегатов стенда) и ее взаимодействия с ПО удобно использовать диаграмму развертывания щьЕрь, расширив ее стереотипами, свойственными ИИС.
• Для представления структуры таблиц СУБД, в которых хранится измерительная информация, считываемая и записываемая в процессе испытаний ВР, можно использовать UML-диаграмму объектов Щою, расширенную новыми стереотипами для представления объектов баз данных согласно [3].
• Для представления методик управления стендом использовать UML-диаграмму деятельности щ^™, расширив и формализовав ее для измерительных задач. В частности, целесообразно улучшить механизм представления временных ограничений, поскольку в UML применяется неудобный механизм представления временных ограничений (с помощью словесного описания в фигурных скобках, которое часто является двусмысленным).
• Для представления графа переходов машины состояний ПО ИСВР использовать UML-диаграмму состояний щм.
Таким образом, множество моделей ИИС ИСВР, созданных в нотации UML, можно представить как:
yUML = {ЩоЮ, Щdepl - ЩFUN ЩSM} (1)
Использование других UML-диаграмм для представления модели ИСВР нецелесообразно в силу следующих причин:
• Несмотря на то, что этот язык моделирования дает возможность рассмотреть систему с самых различных сторон, он является общим и требует много времени для изучения (9 различных диаграмм, у каждой из которых свое представление). Из-за отсутствия формальной семантики это часто ведет к неоднозначности восприятия структурных диаграмм.
• Применительно к ИСВР, выявляется еще один недостаток, а именно сложность представления взаимодействия параллельных задач и процессов. Как правило, ПО ИСВР, управляющая испытательным стендом, включает в себя множество таких задач и процессов (например, измерение сигналов, алгоритмы управления, математическая
обработка данных, графический интерфейс и др.). С точки зрения объектной модели, такая программа состоит из множества активных объектов, каждый из которых использует группу взаимосвязанных классов. В UML трудно представить такое взаимодействие, даже если для представления активного объекта использовать пакет. Диаграмма получается громоздкой и ненаглядной. Это происходит вследствие более сложного (чаще всего асинхронного) взаимодействия активных объектов по сравнению с взаимодействием пассивных объектов, функции которых вызываются синхронно.
• Нотация UML (также как и все более ранние нотации, кратко перечисленные выше) была разработана для поддержки процесса проектирования конкретной программы, однако не могут адекватно представлять архитектурное основание ПО ИСВР, поскольку последнее требует более абстрактного описания и исключения склонности к конкретной реализации. Это делает использование UML-диаграмм классов, объектов и взаимодействий слишком трудоемким и ненаглядным. Единственная в данном случае диаграмма компонентов может представлять основные повторно используемые части (компоненты) системы, но на наш взгляд, плохо отражает их взаимодействие.
• Нотация UML не дает возможности точного представления аспектов ИИС ИСВР с помощью математических формул, что приводит к двусмысленности семантики моделей. Их интерпретация сильно зависит от конкретного человека, что ведет к ошибкам на стадии проектирования. Отметим также, что модель, описанная в нотации UML, трудно поддается формализации. Формулы, задающие ее модель, будут слишком запутаны и сложны при восприятии.
Удобным расширением UML является нотация UML Real-Time (UML RT) [15], разработанная специально для систем реального времени (к которым также принадлежат ИИС ИСВР). По сути UML RT является интеграцией нотации для систем реального времени ROOM [15] в UML. В основе этой нотации уже лежит модельный каркас, что значительно повышает уровень ее абстракции. На UML RT-диаграмме взаимодействия можно наглядно представить многопотоковую архитектуру ПО ИСВР: активные объекты представлены в виде множества капсул (Capsules) - Ас, которые могут быть в свою очередь разложены на подкапсулы (SubCapsules) - As : AscAc , являющиеся более мелкими архитектурными элементами и т. д. Динамику каждой капсулы можно представить собственной машиной состояний, заданной графом G(U,V) и характеризующейся множеством правил перехода между состояниями TM, где U - множество состояний (вершин графа), а V - множество переходов из одного состояния в другое.
Обмен между капсулами осуществляется через множество объектов-портов Pc, которые могут быть внутренними (relay ports) -Pcr или конечными (end ports) -Pce : P = {Pcr,Pce), PccAc. Порт представляет интерфейс для взаимодействия с внутренним состоянием капсулы (например, реализует очередь сообщений). Протокол обмена между капсулами хранится в множестве классов-протоколов (Protocol Classes) - Rc. Каждый класс-протокол является набором входных Fn={f1,f2,...fk} и выходных F°ut={fuf2,..fi} сигналов, F={Fn,Fut}, посредством которых определяется взаимодействие. Каждый порт выполняет определенную роль в протоколе (Protocol Role) - Rr:Rr cc Rc. Бинарные протоколы определяются бинарным отношением TcRc2 таким, что Б пара ролей {ra,rb}cRr, для которых Б! пара {Ra,Rb} С Rcbm, Ra = Rb, где Rcbin - спецификация бинарного протокола. В остальных случаях протоколы
определяются n-арным отношением TcRfn таким, что найдется подмножество ролей Rr ={r¡,r2,...rn}, Rr cRr, причем для \/rjGRr 3!RjgRc, i=1...n, j=1...m, m<n, где Rc={Ri,R2,..Rm}.
Таким образом, диаграмма взаимодействия может быть использована для представления многопотоковой модели ПО ИСВР:
lfUML RT = y(Ac,TSM,G(U,V),Pc,Rc) (2)
Одним из важнейших достоинств UML RT является прозрачность представления распределенных систем.
Таким образом, для представления динамических аспектов модели ПО ИСВР удобно использовать UML RT-диаграмму взаимодействия, связав ее с остальными UML-диаграммами следующим образом:
• Важно так представить UML-диаграмму состояний, чтобы она адекватно отображала взаимодействия на UML RT - диаграмме.
• Расширить и формализовать UML-диаграмму деятельности таким образом, чтобы она была согласована ее с UML Real-Time диаграммой.
Проблемой остается представление архитектурного основания (каркаса) ПО ИСВР и его формализация. К сожалению, ни одна из вышеперечисленных нотаций не подходит для представления каркаса ПО ИСВР вследствие недостатка абстрактности и отсутствия точного и формального описания моделей. Поскольку создание каркаса приложения является одной из самых сложных программных задач, то при его описании и анализе важное место должно отводиться математическому моделированию.
Чтобы наметить пути решения проблем точности и формальности при представлении каркаса ПО ИСВР, необходимо проанализировать различные методы для улучшения точности нотаций, в частности и нотации UML. Согласно [9] основными направлениями таких разработок является интеграция ОО нотаций и формальных спецификаций [5, 6, 12] или внедрение ОО особенностей в имеющиеся формальные спецификации [7, 13]. В связи с этими направлениями, ряд статей был посвящен формализации популярной нотации UML [8, 9]. Однако из-за плохой компактности UML (9 диаграмм, каждая из которых имеет свой синтаксис и семантику), в [9] представлена громоздкая формализация только статической диаграммы классов, тогда как остальные 8 диаграмм, входящих в состав UML, оставлены без внимания.
Еще один путь - это расширение ОО нотаций таким образом, чтобы они стали более точными. В [4] в UML введено понятие системной модели, представленной формально, с помощью которой производится интеграция всех моделей UML и таким образом улучшается абстрактность модели. Для уменьшения сложности формализации введен уровень между синтаксическим описанием и чистой математикой. Несмотря на правильно выбранное направление по формализации UML, в работе задачи исследования только заданы и их решение потребует огромных затрат времени вследствие сложности нотации.
Существуют и чисто формальные методы, созданные специально для представления ОО систем, например [14]. Серьезным недостатком всех этих подходов является необходимость глубокого знания математических методов, использующихся в формальной спецификации. Это становится серьезным барьером при промышленном использовании.
Все это привело нас к необходимости отказаться от использования структурных UML-диаграмм при создании ПО ИСВР и заменить их другими более адекватными методами. Поскольку данная статья посвящена использованию и адаптации нотации UML для ИИС ИСВР, то в данной статье эти методы не рассматриваются.
4. Разработка методик представления физических моделей ИИС испытательных
стендов с помощью UML
Для представления физической модели ИСВР (измерительной аппаратуры и агрегатов стенда) и ее взаимодействия с ПО, согласно п. 3, удобно использовать UML-диаграмму развертывания щокPL, расширив ее стереотипами, свойственными ИИС ИСВР (рис.1).
Рис. 1. Стереотипные узлы измерительной аппаратуры (слева) и агрегатов стенда (справа) для представления их на диаграмме развертывания
Рассмотрим структуру промышленного испытательного стенда для тестирования вертолетного редуктора ВР-252. Его отличительной особенностью является сложность управления двигателями, тормозными генераторами с помощью большого числа органов управления, насосов, задвижек. На стенде используется множество дорогостоящих агрегатов, обладающих ограниченным ресурсом работы. Промышленные испытательные стенды являются очень дорогими установками. Так, стоимость стенда ВР-14 около $1 млн., а стоимость ВР-252 около $2 млн. На таких стендах число аналоговых измерительных сигналов может превышать 50, а цифровых дискретных команд и сигналов может быть более 150. Модели развертывания аппаратных средств ИСВР и компьютерного комплекса ИСВР представлены на рис. 2 и рис. 3.
*<5
= 1 = &
§11
В ¡2
Г 1
\
"Тормозной генератор" СГ2 £ г сз £ 03 50 4-
!
\
х £
£ I !
"Тормозной ©" генератор" СГ1 Ми со" ~ т и 1
\ \
N
¡2
ш 1 ¡2 а
р ! 1
|
\
Т Й| <
1 ¿3
= и Г 1
„
I I §
Ф
03
"м 1
ф £
"м
Ф 50
Р1
"м Г А
Рис. 2. иМЬ-диаграмма развертывания промышленного испытательного стенда для тестирования
вертолетных редукторов ВР-252
Принтер HP695C
Компьютер PIII 500 МГц Монитор 17"
У ✓
UPS
700 Вт
У У
У У ✓
« "Кабельный
"Сетевой "Плата" адаптер"
Модуль" PCI-MIO-16E-4 "Кабельная SC-2050
FP-1600 сборка
У SH6850"
&
У У
"Модуль^ "Модуль
ÜHÍUIOI-OBOI-O дискретного
FP-AO-200 FP-DI-300
у
Монтажный (серия SSR)
"Inputs" 6 DI24B = S13...S18 "Outputs" 2 DO=K1, K2
&
'Тер минальный FP-TB-1
"Outputs" 8 AO 0...20мА = A1...A8
Ый
Терминальный FP-TB-1
"Inputs" 8 DI 24B = S1...S4, S19...S22
&
"Монтажный
"Inputs" 2 AI +/- 20B = B9, B10
&
"Монтажный
(серия SSR)
"Inputs" 8 DI 24B = S5...S12
Рис. 3. UML-диаграмма развертывания компьютерного комплекса стенда испытания редукторов ВР-252
Выходные сигналы стенда представлены в виде векторов Bn1={B1,B2,...Bn} и Sm,1={S1,S2,...Sm}, поступающих от различных датчиков, расположенных на стенде или рассчитываемых в процессе работы ПО ИСВР. Для простоты, эти сигналы показаны как выходные сигналы агрегатов. Управляющие сигналы стенда представлены в виде векторов Aq,1={A1,A2,...Aq} и Kp,1={K1,K2,...Kp}, поступающих от компьютерного комплекса стенда рис.3. На стенде используется измерительная аппаратура фирмы National Instruments (США). Сравнив рис. 2 и рис. 3 можно проследить потоки измерения параметров и потоки управления.
5. Разработка методик представления многопотоковой модели ПО ИИС испытательных стендов с помощью UML Real Time
Как уже было показано в п. 3, для представления многопотокового управления удобно использовать расширение нотации UML для систем реального времени - UML Real-Time. На рис. 4 показана общий вид UML Real Time -диаграммы взаимодействия задач внутри ПО ИСВР.
Дополнения, вносимые в эту диаграмму, основаны на особенностях графической ОО среды LabVIEW GOOP [10], в которой предполагается реализовывать созданную модель ПО ИСВР. Поскольку в LabVIEW [11] нет системной поддержки объектов, то в среде GOOP они представлены косвенно в виде библиотеки виртуальных инструментов. Открытый интерфейс каждого такого класса-библиотеки имеет несколько обязательных функций-членов для доступа к закрытым данным. Объектом является ссылка (Object reference) на копию данных класса. С помощью стереотипных классов UML нами введены понятия графического класса-капсулы (рис. 5, а, б) и графического объекта-капсулы (рис. 5, в). Это целесообразно в связи с тем, что при проектировании ПО ИСВР могут дополнительно использоваться другие ОО среды программирования (например, Visual C++), классы-капсулы и объекты-капсулы которых необходимо представить отдельно на UML RT-диаграммах.
Из рис. 5 видно, что в графической среде программирования LabVIEW используются особые "надтипы" данных. Это кластеры (clusters), элементы управления (controls) и индикаторы (indicators), которые в свою очередь могут представлять более простые типы
данных (целые, вещественные, строки и др.) В связи с этим, в нотацию ЦМЬ были также введены новые типы данных.
Рис. 4. UML Real Time диаграмма взаимодействия задач ПО ИСВР
"GraphicCapsuleClass" Class A
"Embed functions" New() Delete() Get_Data() Get_Data_to_Modify() Set_Modified_Data()
"Object reference" DataLog refnum
"Data members"
Cluster {Indicator:String, Control:Boolen}
My_function()
"ports"
"GraphicCapsuleClass" m
ClassA
DataLog refnum
Cluster
{Indicator:String,
Control:Boolen}
My_function()
"ports"
"Capsule"
MyClass:ClassA
(а) (б) (в)
Рис. 5. Расширение нотации иМЬ ЯТ: (а) - стереотипный графический класс-капсула, (б) - его сокращенная запись, (в) - графический объект-капсула
6. Разработка методик представления алгоритмов управления испытательным стендом
с помощью UML
Одной из важнейших частей ПО ИСВР являются алгоритмы управления испытательным стендом. Каждый отдельный алгоритм должен работать непрерывно в своем потоке (рис. 4), и в зависимости от значений измеряемых входных векторов £ и В программно изменяются выходные параметры в векторах К и А. Сложность представления алгоритмов возникает из-за сильной корреляции входных и выходных векторов между собой в режиме реального времени. Для представления алгоритмов управления хорошо подходит ЦМЬ-диаграмма
деятельности, если ее расширить для удобного представления временных ограничений, а также сделать более компактной
Традиционно, временные ограничения в ЦМЬ располагаются в фигурных скобках рядом с переходом их одного состояния в другое. Нам представляется это неудобным и ненаглядным, поскольку сильно загромождает диаграмму, если ограничений используется много. Для представления временных ограничений нами была введена новая пиктограмма,
Рис. 6. Пиктограмма временного ограничения
Эта временная пиктограмма может разрывать линию перехода из одного состояния в другое или присоединяться к состоянию, которое оно характеризует в соответствие с определенным внутри условием времени. С помощью такого временного ограничения можно значительно уменьшить число ветвлений при представлении алгоритма управления.
Для повышения компактности и формальности диаграммы нами были введены следующие обозначения в выражениях и переходах:
1. Доступ к протоколу обмена представляется с помощью оператора «.»;
2. Следствие выполнения условия представляется с помощью оператора «:»;
3. Выполнение условие обозначается цифрой 1;
4. Невыполнение условия обозначается цифрой 0;
Пример представления алгоритма управления показан на рис. 7:
7. Заключение
Нами расширены нотации UML[2] и UML Real Time[15] для измерительных задач. С их помощью разработаны методики создания моделей физического представления ИИС ИСВР и многопотокового управления ПО ИСВР, а также была формализована UML-диаграмма деятельности и разработана методика компактного представления алгоритмов управления ИСВР. В процессе разработки находится методика создания модели внутренней структуры таблиц СУБД для хранения измерительной информации, записываемой и считываемой в процессе испытаний (согласно п. 3). В будущем предполагается использовать созданные методики для проектирования и наглядного представления моделей любой ИИС ИСВР. Их реализацию предполагается производить на основе измерительной графической ОО среды LabVIEW GOOP [10].
8. Литература
1. Буч Г. «Объектно-ориентированный анализ и проектирование с примерами приложений на С++», -М: «Бином», 1998.
2. Буч Г., Рамбо Дж., Джекобсон А. «UML. Руководство пользователя», - М: «ДМК», 2000.
3. Blaha M., Premerlani W. "Using UML to Design Database Applications", -www.omtassociates.com
4. Breu R., Hinkel U., Hofmann C., Klein C., Paech B., Rumpe B., Thurner V. "Towards a Formalization of the Unified Modeling Language", - www4.informatik.tu-muenchen.de
5. Bruel J.M., France B., Larrondo-Petrir M. "CASE-based Rigorous Object-Oriented Methods",-In A.S.Evans and D.J.Duke, Procs of the 1st Northern Formal Methods Workshop, Springer eWiC series, 1997.
6. Bruel J-M., France R.B. "Transforming UML Models to Formal Specifications", -www4.informatik.tu-muenchen.de
7. Duke D. "Object-Oriented Formal Specification",- PhD thesis, University of Queensland, 1991.
8. Evance A.S. "Reasoning with UML Class Diagrams", - www4.informatik.tu-muenchen.de
9. Evance A., France R., Lano K., Rumpe B. "The UML as a Formal Modeling Notation", -www4.informatik.tu-muenchen.de
10. Jehander J. «Graphical Object-Oriented Programming In LabVIEW», 1999, www.endevo.se
11. Johnson G.W., Jennings R. "LabVIEW Graphical Programming",-McGraw-Hill, 2001.
12. Johnson R., Kilov H. "Can a flat notation be used to specify an OO system: using Z to describe RM-ODP constructs",- In Elie Najm and Jen-Bernard Stephani, editors, Procs of the 1st IFIP Work-shop on Formal Methods for Open Object-based Dis-tributed Systems, pages 407-418, Chapman and Hall, 1996.
13. Lano K., Haughton H. "The Z++ Manual. Technical Report",- Imperial College, 1994.
14. Mens T. "A survey on formal models for OO", - Tech report, 1994, progwww.vub.ac.be
15. Selic B., Rambaugh J. "Using UML for Modeling Complex Real-Time Systems", 1998, www.objectime.com/otl/technical/umlrt.html
