Технология REAL
Многолетний опыт использования технологии RTST убедил нас в достоинствах графического проектирования ПО и сквозного контроля. Очень многие ошибки исчезли – например, нельзя послать сообщение объекту, если он этого сообщения не ожидает, в SDL- диаграммах нельзя использовать атрибут, если он не определен в описании схем объектов и т.д.
Однако постепенно пришло понимание и недостатков RTST. Прежде всего, оказалось, что трудно сразу создать описание классов, да еще в текстовом виде. Мы уже начали продумывать графические формы для описания проектируемой системы на этапах раннего моделирования, но тут появился UML. Мы были знакомы с подходами, которые до этого предлагали Буч, Рэмбо и Якобсон по отдельности, но каждый из них охватывал только отдельные фазы жизненного цикла проектирования ПО. Интеграция этих подходов в едином графическом языке UML коренным образом изменила ситуацию, особенно на начальных этапах проектирования. С другой стороны, в 1990-х годах UML не имел практически никаких средств для определения детальных алгоритмов. Мы решили использовать наш опыт и объединить подходы UML и SDL в одной технологии [34]. Новая технология получила название REAL – с одной стороны, хотелось подчеркнуть преемственность с RTST и системами реального времени, с другой стороны, мы надеялись, что новая технология окажет реальную помощь создателям ПО.
Как и прежде, мы приложили много усилий, чтобы обеспечить полноту и сквозной характер технологии. Если технология поддерживает все фазы жизненного цикла программирования, кроме какой-то одной (особенно где-то в середине жизненного цикла), то можно быть уверенным, что большинство ошибок будет именно там. Если разработчик изменил что-то на ранних фазах проектирования, а технология не отметила каким-то образом все места в более поздних фазах, затронутые этим изменением, развитие и сопровождение системы становится практически невозможным. Было очень непросто подобрать английский эквивалент понятию "сквозной характер технологии" при объяснении основных идей REAL иностранным заказчикам.
В конце концов, один американец предложил перевод "drill down — просверленный". Кажется, это подходит.
Теперь приступим к изложению основных идей REAL, точнее, я поясню, как мы понимаем способы проектирования сложного ПО и то, как REAL поддерживает этапы проектирования. На наш взгляд, проектируемая система должна быть аккуратно описана с трех точек зрения.
Пользовательский уровень (иногда говорят "уровень требований"). Система описывается как "черный ящик", задаются все интерфейсы с внешним окружением, для каждого интерфейса дается его вербальное описание, т.е. описание на русском, английском или каком-то другом языке (человеческом, а не формальном). Интерфейсы задаются с помощью диаграмм случаев использования, для каждого случая использования строится диаграмма функций, которые система должна уметь исполнять.
Структурный уровень. Для каждой функции рисуется диаграмма объектов, которые вместе могли бы реализовать эту функцию. Часто для разных функций удается использовать объекты одного и того же типа или находятся объекты, которые лишь слегка отличаются друг от друга. Тогда приступают к созданию диаграммы классов. Класс — это тип (или схема в терминах баз данных), а объекты – это экземпляры значений какого-то типа (т.е. какого-то класса). Если два объекта Об1 и Об2 являются экземплярами похожих классов, то в диаграмме классов удобно использовать наследование:
Здесь класс Кл содержит атрибуты и методы, общие для двух классов, а классы Кл1 и Кл2 содержат описания, специфические для каждого класса. Объект Об1 содержит все атрибуты и методы, описанные в классах Кл1 и Кл, объект Об2 – все атрибуты и методы из Кл2 и Кл.
Если классы Кл1 и Кл2 не могут существовать без класса Кл, используется агрегирование:
Объекты агрегированных классов нельзя уничтожать по отдельности – только все вместе.
Поведенческий уровень. Здесь описывается динамическое поведение системы. Ранние версии UML слабо поддерживали этот уровень, поэтому мы решили использовать стандарты ITU-T (международного союза по телекоммуникациям).
В 2004 году появились предварительные версии UML 2.0, которые перекрывают возможности SDL, и мы уже приступили к их изучению и реализации.
Первым типом диаграмм на поведенческом уровне являются MSC-диаграммы (Message Sequence Chart – диаграмма последовательности сообщений), рекомендация ITU-T Z.120.
Исчерпывающее описание поведения системы на MSC, включающее в себя так называемые "обратные ветки" (обработка аварийных ситуаций и т.п.), оказалось слишком громоздким, поэтому мы расширили язык MSC, включив туда текстовые формы для ветвлений, процедуры-функции, возвращающие результат обработки, и некоторые другие возможности. Впрочем, при желании можно автоматически сгенерировать по расширенному MSC куда более громоздкий, зато стандартный вариант.
Если проектировщик не поленился и представил в MSC-диаграммах действительно полное описание поведения системы, появляется возможность впервые определить поведение каждого объекта по отдельности (до сих пор мы говорили о системе в целом). Перебираются все вертикальные линии (объекты) на MSC-диаграмме, каждая линия рассматривается во всех сценариях поведения. Работа объекта представляется в виде последовательных устойчивых состояний, в каждом состоянии объект ждет определенных сигналов. Получив один из возможных сигналов (сообщение), объект переходит в следующее состояние. Таким образом, получается конечно-автоматная модель объекта (STD – State Transition Diagram), которую можно рассматривать как скелет, основную схему поведения объекта. Здесь еще нет ветвлений, присваиваний, вызовов функций и т.п., но основные контуры поведения объекта уже есть. Ранее этот переход от MSC к STD рассматривался как самый трудный момент проектирования сложных систем. В 2004 году аспирант нашей кафедры системного программирования Владимир Соколов придумал и реализовал систему автоматической генерации STD по MSC. В отличие от других известных нам методов (собственно, более-менее существенный результат мы знаем только один [35]), В. Соколов предоставил проектировщику возможность влиять на структуру генерируемого автомата, что существенно повысило удобство работы и качество получаемого результата [36].
Имея качественную STD-модель, уже нетрудно преобразовывать ее в STL-диаграмму ( Specification and Description Language, рекомендация ITU-T Z.100). Прежде всего, определяется, когда и при каких условиях этим объектом посылаются сообщения, затем добавляется работа с базами данных, какие-то вычисления и т. д.
SDL-диаграмма является конечным продуктом проектирования, конвертация в выбранный промежуточный алгоритмический язык высокого уровня (АЯВУ) и трансляция в объектные коды происходят автоматически. Технология REAL предусматривает определенные правила работы проектировщиков ПО, например, нельзя вносить правки непосредственно в тексте на АЯВУ, все исправления нужно вносить только в SDL-диаграммы, контроль версий следует вести в терминах объектов, а не каких-то промежуточных файлов и т.д. Все попытки горе-проектировщиков "для скорости" нарушить правила и влезть куда-то "грязными руками" приводят к огромным трудностям в дальнейшем развитии системы и сопровождении, поэтому все развитие технологии REAL направлено на ужесточение контроля – делается все, чтобы корректные действия пользователя были легкими и удобными, а попытки совершить некорректные действия блокировались.
Постепенно общее развитие технологии REAL разделилось на два направления. Первое связано с традиционной областью применения – системы реального времени. Здесь главной является SDL-диаграмма, в технологию добавляются различные средства снятия и анализа трасс сигналов, имитаторы нагрузки, эффективные способы организации вычислительного процесса.
Второе направление связано с проектированием информационных систем. Лидером этого направления стал Александр Иванов, который придумал и реализовал средства автоматической генерации различных форм ввода и вывода информации, средства разграничения прав доступа, учета связей между различными атрибутами и т.д. [37]
В этом варианте технологии главной является диаграмма классов. По ней автоматически строится описание базы данных на языке DDL (data definition language), программы CRUD (Create, Read, Update, Delete, т.е.создать, прочитать, исправить, удалить), API (Aplication Program Interface – интерфейс программных приложений) для работы с реляционной базой данных как с объектно-ориентированной. По этой же диаграмме генерируются программы работы с визуальными формами, а с помощью диаграммы объектов задаются связи между атрибутами и ограничения прав доступа.
Программа "Студент" [38], автоматизирующая деятельность деканатов и ректората нашего университета (а также многих других университетов) практически полностью автоматически сгенерирована, и лишь очень малый процент подпрограмм был написан вручную на Visual Basic.
