Генерация представлений моделей UML с целью их инспектирования

Цель дипломной работы состоит в выработке единого систематизированного подхода к инспектированию моделей UML и частичной автоматизации этого процесса.

Программное средство Rational Rose является одним из главных существующих сейчас CASE средств, ориентированных на поддержку языка UML. UML — это сравнительно недавно появившийся язык объектного моделирования. Главное назначения языка UML состоит в анализе и проектировании ПО, а также в построении и сопровождении. Возможности языка UML логичнее всего показать описывая возможности ПС Rational Rose.

Как и любое современное CASE средство, Rational Rose поддерживает все стадии жизненного цикла ПО и предоставляет пользователю широкий спектр функций для анализа, проектирования, построения и сопровождения ПО. При этом используются объектно-ориентированные технологии и широко применяются графические модели.

Rational Rose состоит из следующих основных компонент:

• а) структурное дерево модели для навигации по ней — её объектам и диаграммам, располагается в левой части браузера. В нём отображается модель требований, логическое представление модели, модель компонент системы, модель размещения.
• б) графическое представление модели в виде набора диаграмм — отображается справа от структурного дерева. При выборе какой-либо диаграммы в структурном дереве, она отображается справа от него.
• в) генератор документов — в Rational Rose заложены мощные возможности для генерации различной документации по модели, в том числе генерации сайтов.
• г) расширения для поддержки различных языков программирования, с помощью которых происходит генерация программного кода по существующей модели.

Моделирование ПС начинается с модели требований. Модель требований состоит из Use Case-ов и Actor-ов. Use case — это один из видов деятельности, процессов, которые способна выполнять система. Actor — некая внешняя для системы сущность, будь то человек или другая система, которая способна инициировать выполнение одного из use case-ов, и/или к которой происходит обращение в процессе выполнения какого-либо use case-а. Таким образом модель требований позволяет понять, каким требованиям отвечает проектируемая система, какую деятельность она способна осуществлять, и как она взаимодействует с внешним миром в процессе осуществления этой деятельности.

На рисунке показана простейшая Use case модель — actor Visitor инициирует деятельность Connecting. В процессе выполнения Connecting происходит обращение к эктору Liver.

Модели UML содержат объекты и классы. Классы отображаются на диаграммах классов. Между классами могут существовать различные отношения. Самое общее из них — ассоциация. Ассоциация — некая связь между объектами, имеющая имя и кратность с обеих сторон (скольким объектам одного класса могут соответствовать несколько объектов другого класса). Помимо простой ассоциации возможно также отношение агрегации (взаимосвязь типа часть-целое), отношение обобщения (отношение типа класс-потомок), отношение зависимости, и некоторые другие. У классов могут быть State-диаграммы, описывающие поведение класса — в каких состояниях может находиться класс, какие действия выполняет в каждом из состояний, при переходе от состояния к состоянию, при каких условиях этот переход происходит. Классы группируются в пакеты. Rational Rose позволяет определить набор пакетов, взаимосвязи между ними и представить составляющие их классы на вложенных диаграммах классов.

Для моделирования поведения и взаимодействия объектов классов системы существуют диаграммы взаимодействия, или Sequence-диаграммы. Важность таких диаграмм для проектирования системы огромна, на них отображены последовательности событий, возникающих в процессе общения объектов.

Для каждого вида деятельности можно построить Activity-диаграмму, описывающую какие действия и в какой последовательности выполняются в процессе выполнения некой деятельности (Use Case-а) с возможным указанием того кто эти действия выполняет.

Состав компилируемых и выполняемых модулей системы задается в Rational Rose с помощью диаграммы компонентов. На диаграмме определяются зависимости между компонентами. Для компонентов могут задаваться интерфейсы, через которые реализуются зависимости. Диаграммы развертывания в Rational Rose отражают конфигурацию исполняемой программной системы и состоят из узлов и отношений взаимодействия между узлами. Узлы включают в себя компоненты, представленные на диаграмме компонентов системы. Для полностью определенной модели можно осуществить генерацию исходных программных текстов на различных объектно-ориентированных языках программирования, поддерживаемых Rational Rose, например Java или C++.

Задачи, актуальность

Существует задача инспектирования модели — просмотр модели с целью выявления дефектов. Инспектирование осуществляется в соответствии со списком вопросов на основе модели UML, а также различной документации, описывающей модель и/или проектируемую систему. Инспектирование позволяет выявить несколько разновидностей дефектов:

• а) Отсутствие необходимого или просто желательного элемента в модели — omission.
• б) Двусмысленность, недостаточная подробность описания чего-либо — ambiguity
• в) Неверная информация — incorrect fact
• г) Лишняя информация — extraneous
• д) Несогласованность различных диаграмм и элементов модели — inconsistency

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

Приведём пример некоторых вопросов:

• 1) Для каждого варианта использования установить — имеется ли однозначное понимание того, какая цель варианта использования, кто заинтересован в его выполнении?
• 2) Для каждого объекта на каждой Sequence диаграмме определить соответствует ли его поведение на диаграмме взаимосвязям соответствующего класса с другими классами на диаграмме классов.
• 3) У каждой ли State-диаграммы существует родительский класс или Use-case?
• 4) Каждый ли класс, имеющий State диаграмму присутствует хотя бы на одной Sequence диаграмме?

Как видим все эти вопросы имеют либо весьма расплывчатые формулировки — как первые два, либо для ответа на них придётся проделать очень большой объём довольно однообразной технической работы (вопросы 3 и 4). Обратим так же внимание что 4-й вопрос применим далеко не ко всем моделям UML — он неприменим к моделям где у классов отсутствуют State-диаграммы, и вся функциональность отображается на Sequence-диаграммах. Соответственно перед нами встают следующие основные задачи.

• а) выработать максимально детализированные шаблоны просмотра моделей для получения ответов на вопросы с расплывчатыми формулировками
• б) для каждого вопроса, который применим не ко всем моделям выработать алгоритм определения применимости вопроса к модели
• в) автоматизировать процесс получения ответов на вопросы в тех случаях когда это возможно, в основном это те случаи когда для получения ответа на вопрос приходится проделать много однообразной технической работы, как в случае вопросов 3 и 4.

Итогом работы должно стать множество тест-кейсов каждый из которых будет состоять из тест-процедуры и ожидаемого результата.

Обзор темы

Одной из главных существующих на сегодня методик инспектирования моделей является OORT — Object Oriented Reading Technique. Этот метод был разработан в америке, в университете штата Мэрилэнд. Основное на что нацелен метод — сравнение различных частей модели, например диаграмм классов и Sequence-диаграмм, с целью выявления несогласованностей между разными частями модели. Попутно при этом выявляются внутренние дефекты каждой конкретной диаграммы и каждого конкретного элемента. Метод состоит из 7-ми частей, части делятся на два класса — горизонтальное чтение и вертикальное чтение. Вот краткие заглавия этих частей метода:

OORT-1: Sequence-диаграммы и диаграммы классов (горизонтальное).

OORT-2: State-диаграммы и описания классов (горизонтальное).

OORT-3: Sequence-диаграммы и State-диаграммы (горизонтальное).

OORT-4: Диаграммы классов и описания классов (горизонтальное).

OORT-5: Описания классов и описания требований (вертикальное).

OORT-6: Sequence-диаграммы и Use Case-диаграммы (вертикальное).

OORT-7: State-диаграммы и описания требований (Use Case-ов)(вертикальное) Отсюда видно что при горизонтальном чтении сравниваются элементы одного уровня (например, и Sequence и State-диаграммы находятся в логическом представлении модели), а при вертикальном элементы из логического представления с элементами из модели требований.

Как уже говорилось, вопросы на которые надо дать ответ зачастую имеют расплывчатые формулировки, часто для ответа на них недостаточно одной лишь модели UML. Например для ответа на вопрос «Охватывают ли варианты использования всю требуемую функциональность системы, и как следствие, выявлены ли все варианты использования?» помимо модели системы потребуется дополнительное текстовое описание системной функциональности.

Недостатки OORT-метода

Каждая из OORT представлена в виде последовательности шагов. На первом шаге выполняются предварительные подготовительные действия, далее осуществляется поиск различных дефектов в соответствии с задачами данного OORT. Приведём пример одного из вопросов в OORT. В OORT1 на одном из шагов надо в том числе выяснить:

• а) все ли сообщения и параметры имеют смысл для объекта?
• б) все ли необходимые атрибуты определены?
• в) все ли отношения (ассоциации и т. д.) данного класса с другими классами оправданы и верны?

Как видим, сами формулировки таких вопросов мало помогают делу. Для таких вопросов, помимо советов по какому принципу на них планируется искать ответ, будут приведены конкретные примеры соответствующих дефектов, т. е. примеры где например из документации явно очевидно отсутствие какого-либо важного атрибута. Ответ на пункт в) в данном случае так же стоит развернуть по смыслу и конкретизировать конкретными примерами.

Ещё один недостаток OORT-метода состоит в том что он нацелен исключительно на инспектирование каждого элемента в отдельности, что не позволяет критически посмотреть на модель в целом. Например отсутствуют такие вопросы как:

Обоснованы ли применения иерархий пакетов вариантов использования, если таковая имеется?

Наиболее важные из вопросов, неучтённых в OORT будут также проработаны.

Наконец вопрос автоматизации также весьма актуален. Например, чтобы определить, для каждого ли объекта, принимающего сообщения на Sequence-диаграмме, соответствующая функциональность отражена в его классе, потребуется пройтись по всем сообщениям каждой Sequence-диаграммы. Такие действия можно автоматизировать.

Одним из существующих средств для такой автоматизации является Rational SoDA. Функции этого программного продукта состоят в выведении всей нужной информации по модели в word-овский файл. Вначале создаётся шаблон, в котором специальными командами прописывается, какая информация будет выведена (например могут быть выведены все activity-диаграммы некоторого пакета, и для каждой activity из таких диаграмм будет выведено содержащееся в модели описание activity). Далее запускается генератор, создающий документ (отчёт) с требуемой информацией. Работа с данным ПС будет рассмотрена подробнее.

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

Для тех тестов, которые нельзя автоматизировать, стоит выбрать то представление модели, в котором её проще инспектировать. И здесь поможет инструмент web-publisher, который генерирует html представление модели в виде сайта. Замечено, что в силу ряда особенностей работы web-publisher-а инспектирование по модельным сайтам производить значительно удобнее. Более того, можно сделать эту задачу ещё приятнее, автоматически русифицировав такой сайт с помощью таблиц подстановки. Текст программы и типовые таблицы подстановки будут приведены далее.

Если обобщить всё вышесказанное то цель, задачи и результат работы можно представить следующим образом.

Цель дефект автоматизация оriented reading.

Выявление дефектов модели UML путём инспектирования.

Задачи

• 1. Подробное изучение методики Object Oriented Reading Technique, получение списка вопросов с абстрактными формулировками.
• 2. Изучение примеров реальных дефектов, отвечающих вопросам из 1.
• 3. Более конкретное и детализированное описание данных вопросов на основе полученного опыта.
• 4. Получение списка вопросов, подлежащих автоматизации.

Выявление тех из них, которые подлежат автоматизации с помощью ПС Rational SoDA, создание примеров шаблонов SoDA для них.

Написание скриптов для вопросов, выявленных в ходе пункта 4, не подлежащих автоматизации с помощью SoDA.

Результат

Список тесткейсов, направленных на инспектирование моделей UML, где каждый тесткейс соответствует одному из вопросов, описанных в OORT. Тесткейсы будут представлены в виде html документов. Тесткейсы, соответствующие вопросам, изученным в ходе 1−3 будут снабжены более детальным описанием с конкретными примерами данных дефектов. Тесткейсы, подлежащие автоматизации SoDA будут снабжены ссылками на примерные шаблоны SoDA, указаниями как создавать аналогичные свои и как интерпретировать результаты отчёта с целью определения наличия или отсутствия данного дефекта в модели. Тесткейсы, для которых будут написаны скрипты, будут снабжены указаниями по применению скриптов к mdl файлам и интерпретации результатов их работы.