Управление жизненным циклом предприятия с использованием инструментальной линейки IBM Rational / Telelogic. IBM Telelogic Tau. Часть 4.

4. И появилась возможность следовать рекомендациям OMG-­группы, а именно: перейти от широко используемой в прошлом стратегии CDA [Code­Driven Architecture] к новой стратегии MDA [Model­Driven Architecture].

Поскольку Tau имеет 2 дополнительных опции ­Tau/Architect и Tau/Developer, - то общий функционал инструмента распределяется следующим образом:

построение модели\­ей с использованием диаграмм, имеющихся в стандарте UML2.1; ­проверка диаграмм на соответствие синтаксису и семантики (нотации) языка UML2.1; ­автоматический поиск и локализация ошибок в диаграммах.

Tau/Architect (Add­On):

­построение модели\­ей с использованием диаграмм, имеющихся в стандарте UML2.1; ­проверка диаграмм на соответствие синтаксису и семантики (нотации) языка UML2.1; ­автоматический поиск и локализация ошибок в диаграммах; ­динамическая проверка поведения модели; ­отработка и корректировка функционала, закладываемого в модель.

IBM Rational / Telelogic Rhapsody является наилучшим инструментом для разработок встраиваемого программного обеспечения (embedded) или систем реального времени (Real­Time System).

Автоматическая кодогенерация на C, C++, Java, отталкиваясь от моделей, выполненных на UML или SysML, позволяет не только получит компактный исходный код для последующей компиляции, но и автоматизировать процесс тестирования.

IBM Rational / Telelogic SDL Suite

Инструмент Telelogic SDL Suite построен на базе международного стандартного языка SDL (Specification and Description Language), официально признан ITU­ETSI, используется ими и рекомендован этими организациями для дизайна систем и приложений для телекома, систем реального времени, встраиваемого программного обеспечения. Следует заметить, что большинство телекоммуникационных протоколов помимо текстового описания уже специфицировано ITU­ETSI с помощью SDL-­диаграмм, для построения которых эти организации также используют Telelogic Tau SDL.

Tau SDL весьма напоминает описанный выше Tau, хотя ради исторической справедливости, следует отметить, что как раз Tau строился, исходя из зарекомендовавших себя с положительной стороны, возможностей Tau SDL:

­имеется опция Simulator, которая в режиме реального времени позволяет моделировать поведение всей системы или ее отдельных частей, с использованием MSС-­диаграмм (диаграмм последовательностей).

­имеется опция Validator, предназначенная для дополнительного поиска ошибок, позволяя находить перекрестные ссылки, "мертвые петли", разрывы в графе, ссылки "в никуда", ошибки ввода-­вывода и т.д.

­имеется кодогенератор, автоматически выдающий до 100% исходного кода на языке С.

Нас часто спрашивают об основных преимуществах использования Tau SDL, который может автоматизировать труд разработчика, по сравнению с ручным написанием кода. Попытаемся ответить...

Большинство ошибок, которые имеются в коде, вносит сам человек. И какими бы профессионалами не были ваши специалисты, ­это неизбежно!

И неважно - создаете ли вы новый протокол, глядя на рисунок (блок­-схему), или пытаетесь что-­то сделать с SDL-­диаграммой, полученной в электронном формате от третьей стороны (причем никто не гарантирует, что вы получите абсолютно отработанную и без ошибок диаграмму). Ошибки всегда есть....

Но дело в том, что те ошибки, ­а мы пока говорим только об ошибках кода, ­которые вносит человек при "ручном" способе программирования, в большинстве своем могут быть найдены только в самом конце работ - на фазе тестирования, а то и эксплуатации. А значит, потребуется время на их исправление, повторное тестирование и т.д.

При этом ошибки создаваемого дизайна (функционал) в вашем случае могут быть найдены только на фазе завершающего тестирования ­при реальных испытаниях. А то, и зачастую, ­только на стороне клиента, ­когда потребуется совпадение во времени многих условий, чтобы выскочил, так называемый, "глюк", и когда повторить эти условия, чтобы найти ошибку, не всегда бывает возможно.

И если не задумываться более ни о чем, то возникает вопрос - а что вам даст замена одного языка программирования (который вы сейчас используете) на другой, если предлагать, что это будет SDL? Однако, вся тонкость в том, что предлагается не просто язык SDL, а инструмент, построенный на базе этого языка-­стандарта, а именно - Tau SDL. А вот в нем­-то и заложена вся сила и немалые возможности, которые будут экономить вам время и деньги...

Tau SDL состоит из нескольких опций, которые разработчик проходит в обязательном порядке с тем, чтобы получить правильный, проверенный, на 100% автоматически сгенерированный код. Ниже приводится краткое описание каждой из основных опций Tau SDL:

1. SDL­Editor + SDL Analyzer.

Используя эти опции, пользователь строит SDL-­диаграммы системы в соответствии с нотацией языка SDL. При этом инструмент - в зависимости от того, с чем работает пользователь - предлагает ему соответствующий набор возможных к использованию составляющих - блоки, функции, процедуры, вставки с комментариями и т.д. Работа пользователя сводится к дизайну системы, который он строит из составляющих как из кубиков, детализируя систему "сверху-­вниз". В процессе работы первая опция Tau SDL ­Analyzer ­проверяет все ваши диаграммы пока только на правильность и соответствие нотациям языка SDL (отметим, ­функционал ПОКА не проверяется).

Показывает обнаруженные ошибки, сообщает (описывает) с чем они связаны и указывает на конкретный символ SDL­-диаграммы, в котором эта ошибка присутствует.

Согласитесь, в таких условиях намного легче искать ошибки (попробуйте представить для сравнения, что легче ­писать по-английски ручкой на бумаге или воспользоваться Word, в котором включен speller английского языка).

Дальше у вас два пути:

­или, глядя на эту диаграмму (поскольку в ней уже нет расхождений с языком) писать код вручную (это ж сколько времени может понадобиться для написания какого-­нибудь современного протокола???!!!), как многие это сейчас и делают (рисуя диаграммы или блок-­схемы в Visio), а значит по-­прежнему вносить ошибки, связанные с человеческим фактором,

­или задействовать следующую опцию Tau SDL.

2. Simulator.

После приведения диаграмм в полное соответствие с нотацией языка (иначе дальше система вас просто не пустит), вы можете воспользоваться опцией Simulator, которая поможет вам отработать систему уже с точки зрения создаваемого функционала (дизайна). Сразу оговоримся, что проверяется либо вся все то, что составляет SDL­-диаграмму или к ней относится (на ваш выбор):

а) или только SDL-­диаграмма системы, блока, подсистемы, модуля... т.е. любой части системы (вот еще один "плюс" ­не надо ждать сборки всей модели\системы),

б) или совокупность SDL-­диаграмм и\или ее частей и вставок с вашим кодом (непосредственно прописывание кода в символах диаграмм или референс на headers. Использование функций языка C, Assembler, например).

При запуске Simulator'а инструмент автоматически переводит вашу SDL-­диаграмму в диаграмму последовательностей MSC (Message Sequence Chart), инициализирует ее и готовится к приему сообщений-­сигналов. Вот теперь вы можете посылать в систему любые сообщения, соответствующие внешним воздействиям и условиям, ­с любыми параметрами и значениями, в любой вход (порт) вашей системы.

Можете посылать сигналы по одному, можете в параллель, можете пачками или по спец­графику с разнесением во времени ­все, что вам угодно. Можете исполнять пошагово, а может от начала и до конца, можете ставить break­points в любом месте SDL- ­или MSC­-диаграммы, поскольку они завязаны между собой. Можете выводить log­файлы, можете ставить watch­ок на  выбранные переменные и многое­ другое. При приходе сигнала в MSC-­диаграмму вы увидите, что происходит в системе - как работают таймеры, как создаются объекты, куда и в какой последовательности поступают сигналы, т.е. - как система отрабатывает входное воздействие в соответствии с тем функционалом, который вы в нее заложили. И на диаграммах вы будете видеть картину поведения всей вашей системы или отрабатываемого блока. Более того, система выдаст вам статистику покрытия, и вы будете знать, насколько полно вы проверили вашу систему посылаемыми сообщениями.

Обратите внимание, ­поверяя функционал ­вы фактически тестируете систему еще в процессе ее разработки.

Вы можете проверять все, что вам угодно, посылать любые сигналы и любыми способами. Ваша задача ­только лишь наблюдать за реакцией системы и делать выводы, ­нужен вам такой функционал или что­-то надо переделать.

Мы еще раз утверждаем, что проверяется все то, что вам необходимо ­в том числе и совместное поведение диаграмм, созданных в Tau SDL, и ваших кодовых вставок в них, если таковые будут делаться. (Этим же путем можно пойти, если вы проверяете на функционал или соответствие нотации даже чужие диаграммы - ведь существует много компаний, которые или продают свои SDL-­диаграммы или отдают их).

Закончили и с этим, теперь у вас на руках имеется диаграмма (или набор диаграмм) системы с проверенным функционалом. После этого у разработчика тоже два пути:

­или, глядя на эту отработанную диаграмму (поскольку функционал уже обеспечен и проблем с этим нет) писать код вручную, как некоторые продолжают делать, а значит по-­прежнему вносить ошибки, связанные с человеческим фактором,

­или задействовать следующую опцию Tau SDL.

3. Validator

Мы рекомендуем второй путь... Включается в работу опция Validator. На основании SDL-­диаграммы системы или ее любой, выбранной вами части, Validator строит дерево поведения системы. Т.е. анализирует все возможные состояния сигналов и их параметров, настройки таймеров, интерфейсы и т.д., и "за кадром" строит дерево всех возможных переходов в системе, "глядя" на дизайн вашей системы. Для чего в систему автоматически засылаются любые случайные наборы вышеперечисленных сообщений, и оценивается реакция системы.

Опять же "за кадром", анализируя реакцию системы, Validator ищет ошибки, которые могут возникнуть в системе, например, при сбое, и выводит вам этот результат, группируя ошибки в однотипные группы.

Правила, по которым опция ищет ошибки, зашиты в ней, но у вас есть возможность их корректировать или добавлять свои. Здесь ищутся, например, посылка сообщений "в никуда", перекрестные ссылки, мертвые петли, ошибки ввода­-вывода и многое другое. (Кликните мышкой на символ ошибки, и опция выведет вас на символ диаграммы, с которым эта ошибка связана ­огромная экономия времени).

Именно здесь вы получите информацию, ­а что будет, если такой­-то сигнал придет раньше, чем закончит работу таймер... хотя в соответствии с вашим дизайном это сообщение должно придти позже, ­но вот, что будет, если такое случится?).

Другими словами, если в опции Simulator вы проверяете и отрабатываете поведение системы на "правильность", то в Validator ­на неправильность, т.е., как будет реагировать система, если в нее попадутся сигналы с не теми параметрами, не в то время и не в том порядке, если таймеры закончат свою работу позже\­раньше против ожидаемого и т.д. Попробуйте смоделировать такое на реальном стенде, ­да вам несколько лет только сам стенд создавать придется.  А мы предлагаем делать все это, ­сидя за компьютером, без специальных стендов, в режиме времени (пока не пишу "реального" времени).

Все это нужно лишь для того, чтобы на выходе вы получили систему, в которой нет ошибок, потому как еще на стадии ее создания, вы их все убрали, трижды все перепроверив.

После этого у разработчика тоже два пути: ­или, глядя на полностью отработанную диаграмму писать код вручную, как некоторые иногда делают, а значит по-­прежнему вносить ошибки, связанные с человеческим фактором, ­или задействовать одну из самых мощных и важных опций Tau SDL.

4. Code Generator

Если вы выбираете второй путь, то дальнейшие шаги просты - открываете окно, задаете опции кодогенератора, нажимаете клавишу и получаете исходный код на ANSI.C (на базе созданных диаграмм и всех и любых кодовых вставок, заметьте), который можете потом компилировать любым вашим родным компилятором.

Настроечных опций здесь великое множество. Перечислим лишь некоторые из них (пользователь должен пометить их): ­должен ли сгенерированный код содержать специальные вставки, сообщающие вам о тех или иных ошибках (error checking); ­если ДА, то отмечаете, какие именно ошибки вас интересуют; ­каким образом будет полученный код "заливаться" в исходное железо; ­делать ли "закладки", чтобы выводить служебную информацию на какой­-либо порт, используемый для отладки; ­предполагается ли наличие или отсутствие операционной системы в вашем устройстве; ­если операционка будет, то какая именно ОС (мы уже поддерживаем массу известных ОС, готовы интегрироваться с вашей собственной, или разработать такую интеграцию для вас); ­можете собственноручно определять работу с очередями или воспользоваться критериями ОС и т.д. Причем, каждый раз, меняя эти настройки, вы тут же будете получать новый код с учетом ваших пожеланий, ­не занимаясь "ручной" корректировкой кода. Сколь угодно часто, сколь угодно долго ­хоть 24 часа в сутки и 30 дней в месяц. Но после того как код получен, ­вот тут уже мы категорически не рекомендуем "трогать" полученный код ­во избежание внесения ошибок.

Разумеется, поскольку код генерит машина, он хоть и получается без ошибок, но имеет некоторую переизбыточность ­очевидцы называют цифру в 3­5%. Поэтому, если ­в силу специфических причин ­вам требуется оптимизировать полученный код на все требуемые 100%, то у вас есть возможность "вырезать" кусок SDL-­диаграмм и написать этот кусок хоть на Ассемблере. После этого можно смело "заливать" этот код в ваше железо, ­все будет работать, будьте уверены.

Но и тут мы не останавливаемся на достигнутом.. Tau SDL имеет два кодогенератора: ­C­micro для систем критичных к "размерам" (например, 8­битовый процессор, без ОС) и C­advanced для 64­битовых процессоров, многопоточных задач, многопроцессорных систем. Все остальное - лежит между ними.

Последняя опция ­Code Generator ­отрабатывается нашей компанией уже десяток лет и не может генерить ошибок по сути, поскольку просто использует отработанные конструкции языка и модули ­макросы, например. При этом никакой отсебятины кодо­генератор не пишет. Следует помнить, кодогенератор может использоваться на всем протяжении работ, а значит, у вас есть возможность искать недоразумения, ­если они будут ­с самого начала. А не искать проблемные места в готовом результате, если писать что-­то вручную. Т.е. на этом можно считать процесс создания кода (не пишу "написания" кода) завершенным. Вы получили то, к чему шли. Но намного быстрей и качественней. Однако и тут мы можем предложить вам продолжение.

5. Target Tester

В системах реального времени очень важно иметь возможность контролировать (или оценивать) время исполнения кода (или, по другому ­время задержки в коде).

Для этих целей у Tau SDL имеется опция, которая носит название Target Tester (эта опция хоть и носит название tester, и могла бы быть отнесена к этапу тестирования, но входит в состав Tau SDL- инструмент дизайна).

Вы даете задание кодогенератору сгенерировать код с учетом вывода дополнительной информации на порт, который используется в вашей системе для отладки (см. выше). Подключаете к этому порту свой компьютер с пакетом Tau SDL и делаете с вашей реальным "железом" все, что хотите (я имею в виду нечто похожее на реальные манипуляции: в АТС это ­снимать трубки, устанавливать связь, набирать цифры; в системах исполнения - срабатывание реле, нажатие кнопок и т.д.). На основе информации, которая поступает через порт (и, сопоставляя ее с имеющимися диаграммами), Tau SDL построит вам MSC-­диаграмму поведения вашей реальной системы. Т.е. в режиме времени вы сможете наблюдать на экране последовательность и динамику тех реальных процессов, которые происходят ВНУТРИ вашей реальной системы, сможете контролировать их, и оценивать, и корректировать, возвращаясь к первичным диаграммам.

Инструмент Tau SDL уже давно и по праву имеет заслуженную репутацию.

Недаром же все известные вам телекомовские компании мира и не только они ­наши клиенты: ITU, ETSI, Alcatel, Nortel, Ericsson, Lucent, Motorola, Nokia, Cisco, NEC, Siemens, Matra, Schlumberger, Tektronix, 3Com, Sprint, Intel, British­France­Deutsche Telecom, Sony, Panasonic, NASA, Mercedes, Toyota, BMW, Ford, Volkswagen, Boeing, Lockheed Martin, Fujitsy, Kodak и т.д.

Слово пользователям:

"Время выхода продукта сократилось с 15 месяцев до 3... Благодаря высокому качеству исполнения, трудно ожидать чего­-либо лучшего, чем уже достигнутый результат с нулевым числом ошибок"

Ericsson

"Автоматизированный процесс тестирования с помощью IBM Rational / Telelogic Tau на 70% сократил стоимость разработок"

Lucent

"Потребовалось бы около 6 месяцев, чтобы получить результат, если писать код вручную... и это в то время, когда при использовании генератора кода, это вопрос лишь нескольких минут.."

Motorola

"...[Tau SDL] позволяет нам получать результат намного быстрее, чем при использовании традиционных способов программирования. А т.к. весь цикл разработки при этом значительно сокращается, то это и является причиной номер один, ­почему мы этим пользуемся"

Nokia, ATM

"Испытания показали пятикратное повышение качества"

Motorola, TETRA

"Использование IBM Rational / Telelogic Tau [SDL] экономит нам 53% времени и позволяет получать продукт, который не "привязан" к конкретной платформе..."

Vocalis, UK

Если у вас появится желание протестировать работу IBM Rational / Telelogic Tau на своем рабочем месте, то обратитесь к нам (mail@interface.ru), и мы организуем для вас evaluation последней версии продукта со всеми теми опциями, которые вам необходимы.